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The purpose of this publication is to 
enable programmers to compile, linkage 
edit, and execute COBOL (F) programs under 
control of IBM System/360 Operating System. 
The COBOL (F) language is described in IBM 
System/360 Operating System: COBOL Lan- 

uage, Form C28-6516, which is a corequi- 
Site to this publication. 


Programmers who are unfamiliar with the 
concepts of System/360 Operating System 
should read the "Introduction," "Using the 
DD Statement," "A Checklist for Job Control 
Procedures," and “Cataloged Procedures." 
These chapters provide information about 
the preparation of COBOL programs for proc- 
essing by the operating system. 


Programmers who are familiar with the 
operating system and wish to know how to 
run COBOL programs should read ‘Options for 
the Compiler and Linkage Editor‘ under 
"Format of the Job Control Statements, " 
"Compiler Data Set Requirements," "Linkage 
Editor Data Set Requirements," "Execution 
Time Data Set Requirements," and "Output" 
in addition to the four chapters listed 
above. 


Chapters “Program Checkout" and "Pro-. 
gramming Techniques" are of special inter- 
est, Since they contain information about 
debugging and efficient programming. Other 
chapters discuss optional features of the 
language and the operating system. Some 
chapters include introductory information 
about features of the operating system 
which are described in detail in other 
publications. 


The machine configuration required for 
system operations is described in the 
chapter “Machine Considerations." 


PREFACE 


Wider and more detailed discussions of 
the operating system are given in the fol- 
lowing publications: 


IBM System/360 Operating System: Job 
Control Language, Form C28-6539 
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IBM System/360 Operating System: Sys- 
tem's Programmer's Guide, Form C28-6550 


IBM System/360 Operating System:  Super- 


visor and Data Management Services, Form 
C28-6646 


IBM System/360 Operating System: Super- 


visor and Data Management Macro- 
Instructions, Form C28-6647 
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Merge, Form C28-6543 


IBM System/360 Operating System: Utili- 
ties, Form C28-6586 
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IBM System/360 Operating System: Mes- 
sages, and Codes, Form C28-6631 
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A COBOL (F) program is processed by the 
System/360 Operating System. The operating 
system consists of a number of processing 
programs and a control program. The proc- 
essing programs include the COBOL (F) com- 
piler, service programs, and user-written 
programs. 


The control program supervises the 
execution of the processing programs; con- 
trols the location, storage, and retrieval 
of data; and schedules jobs for continuous 
processing. 


A request to the operating system for 
facilities and scheduling of program execu- 
tion is called a job. For example, a job 
could be execution of the COBOL (F) compil- 
er to compile a program. A job consists of 
one or more job steps, each of which speci- 
fies execution of a program. A programmer 
makes these requests to the operating sys- 
tem by use of job control statements that 
may be punched into cards. 


Each job is headed by a JOB statement 
which identifies the job. Each job step is 
headed by an EXEC statement which describes 
the job step and calls for execution. 
Included in each job step are DD state- 
ments, which describe data and request 
allocation of input/output devices. 


The data processed by execution of any 
processing program must be in the form of a 
data_set. A data set is a named, organized 
collection of one or more records that are 
logically related. Information in a data 
set may or may not be restricted to a spe- 
cific type, purpose, or storage medium A 
data set may be, for example, a source pro- 
gram, a library of subroutines, or a file 
of data records that is to be processed by 
a COBOL program. 


A data set resides in one or more 
volumes. A volume is a unit of external 
storage that is accessible to an input/ 
output device. For example, a volume may 
be a reel of tape or a disk pack. 





To facilitate retrieval of a data set, 
the serial number of the volume upon which 
it resides can be entered, along with the 
data set name, in the system catalog of 
data sets. The catalog itself is a data 
set residing on one or more direct-access 
volumes. It is organized into indexes that 
relate each data set name to its location-- 
the volume in which it resides and its 
position within the volume. Only the data 
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set name need be specified to identify a 
cataloged data set to the system. 


The catalog is Originally created by a 
utility program. Once the catalog exists, 
any data set residing on either a direct- 
access Or a magnetic tape volume can be 
cataloged automatically by use of a catalog 
subparameter in a DD statement that refers 
to the data set. 


Several input/output devices grouped 
together and given a single name when the 
system is generated constitute a device 
class. Each device class can be referred 
to by a collective name. For example, one 
device class called SYSDA could consist of 
all the direct-access devices in the 
installation; another called SYSSQ could 
consist of all the direct-access devices 
and tape devices. 


DATA_SET_ ORGANIZATION 


A data set used by a COBOL program can 
have cne of five types of organization: 
sequential, indexed sequential, direct, 
relative, and partitioned. The first type 
(sequential) may be on any input/output 
device. All other types must be on direct- 
access devices. 


1. A sequential data set is one in which 
records are organized solely on the 
basis of their successive physical 
positions, such as they are on tape. 


2. An indexed sequential data set is one 
in which records are arranged in log- 
ical sequence (according to a key 
which is part of every record) on the 
tracks of a direct-access device. A 
separate index or set of indexes main- 
tained by the system indicates the 
location of each record. This permits 
random, as well as sequential, access 
to any record. 


3. A direct data set in COBOL is one in 
which records are referred to by use 
of relative track addressing. An 
actual key specifies the track rela- 
tive to the first track allocated to 
the data set. A symbolic key identi- 


fies the record on the track. 


4. A relative data set in COBOL is one in 
which records are referred to by use 
of relative record addressing. A sym- 


bolic key identifies the record loca- 
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tion relative to the first record in 
the data set. 


5. A partitioned data set (PDS) is one 
that is composed of named, independent 
groups of sequential data, each of 
which is called a member. Each member 
has a simple name stored in a direc- 
tory which is part of the data set and 
which contains the location of each 
member's starting point. Partitioned 
data sets are used to store programs, 
and are often referred to as 
libraries. 


EXECUTING A COBOL PROGRAM 


me a ee ee et es ee ee 


Three basic operations are performed to 
execute a COBOL program: compilation, 
linkage editing, and actual execution. 


COMPILATION 


Compilation is the process of translat- 
ing a COBOL (F) source program into a 
series of instructions comprehensible to 
the computer, i.e., machine language. In 
operating system terminology, the input to 
the compiler, the source program, is called 
the source module. The output from the 
compiler, the compiled source program, is 
called the object module. 


LINKAGE EDITING 


The linkage editor is a service program 
that prepares object modules for execution. 
It can also be used to combine two or more 
separately compiled object modules into a 
format suitable for execution as a single 
program. The executable output of the 
linkage editor is called a load module, 
which must always be stored as a member of 
a partitioned data set. 


In addition to processing object 
modules, the linkage editor can combine 
previously edited load modules, with or 
without one or more object modules, to form 
one load module. 


During the process of linkage editing, 


external references between different 
modules are resolved. : 


EXECUTION 


Actual execution is under supervision of 
the control program, which obtains a load 
module from a library, loads it into main 


10 


storage, and initiates execution of the 
machine language instructions contained in 
the load module. 


SYSTEM/360 OPERATING SYSTEM ENVIRONMENTS 


System/360 Operating System offers three 
control programs. These are the Primary 
Control Program, Multiprogramming with a 
Fixed Number of Tasks, and Multiprogramming 
with a Variable Number of Tasks. 


PRIMARY CONTROL PROGRAM (PCP) 


The primary control program (PCP) of the 
Operating System provides all sequential 
scheduling features of the Job Control Lan- 


Operating System: __Operator’s_ Guide 
C28-6540. It affords data management capa- 
bility and contains a supervisor that pro- 


vides for: 


e Efficient overlapping of central proc- 
essing unit operations and input/output 
channel activity 


e Error checking and standard input/ 
output error recovery procedures 


e Supervision and processing of 
interruptions 


e Supervision of requests for various 
services provided by the system 


This control program provides for a 
Single input job stream and the sequential 
processing of job steps through single task 
operations. 


MULTIPROGRAMMING WITH A FIXED NUMBER OF 
TASKS (MFT) 


The MFT control program divides storage 
into a number of discrete areas called par- 
titions. Job steps are directed to these 
partitions using a priority scheduling sys- 
tem; that is, jobs are not read in as 
encountered in the job stream but according 
to a priority code. In addition to the 
facilities provided by the primary control 
program, the MFT control program provides 
for: 


e priority scheduling of jobs using the 
class code 


e concurrent scheduling and execution of 
up to 15 separately protected jobs 


e reading one or more input streams 


MULTIPROGRAMMING WITH A VARIABLE NUMBER OF 
TASKS (MVT) 


The MVT control program divides storage 
into areas called regions. Like MFT, the 
MVT control program uses a priority sched- 
uling system provides for concurrent execu- 
tion of up to 15 jobs, and reads more than 


one input stream. In addition, the MVT 


control program: 


* assigns storage regions on a variable 
basis according to a region code 


For further information about the 
various optional features of the System/360 
Operating System, see the publications IBM 


System/360 Operating System: Storage Esti- 
Mates, Form C28-6551, and IBM System/360 


Operating System: Concepts and Facilities, 
Form C28-6535. 
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The sequence of job control statements 
required to specify a job is called a job 


control procedure. 


For example, the job control procedure 
shown in Figure 1 could be placed in the 
input stream to compile a COBOL source 
module. 


JOB1 is the name of this job. The JOB 
statement indicates the beginning of a job. 


STEP1 is the name of the single job step 
in the job. The EXEC statement specifies 
that the COBOL (F) compiler (IEQCBLO0O) is 
to execute the job. The statement also 
specifies that a card deck of the object 
module is to be produced (PARM=DECK). 


The SYSUT1, SYSUT2, SYSUT3, and SYSUT4 
DD statements define utility data sets used 
by the compiler to process the source 
module. The names of the data sets defined 
by SYSUT1, SYSUT2, SYSUT3, and SYSUT4 are 
&UT2, &UT3, and 6UT4, respectively. 6&UT1, 
SYSUT1 must be on direct access (UNIT= 
SYSDA). The system is to allocate 40 
tracks of space to SYSUT1. The other three 
utility data sets are assigned either to 
any available tape, in which case the SPACE 
parameter is ignored, or to a direct-access 
unit (UNIT=SYSSQ). 


The SYSPRINT DD statement defines the 
data set that is to be printed. SYSOUT=A 
is the standard designation for data sets 
whose destination is the system output 
device, usually indicating that the data 
set is to be listed on a printer. 


The SYSPUNCH DD statement defines the 
data set that is to be punched. SYSOUT=B 
is a standard designation for a card punch. 


JOB CONTROL PROCEDURES 


The SYSIN DD statement defines the data 
set (in this case the source module) that 
is to be input to the job step. The 
asterisk (*) indicates that the input data 
set follows in the input stream. 


The delimiter (/*) statement separates 
data from subsequent control statements in 
the input stream. 


Output from this job step includes any 
diagnostic messages associated with the 
compilation. They are printed in the data 
set specified by SYSPRINT. 


Note: SYSDA, SYSSQ, B, and A are IBM- 
specified device class names. If they are 
to be used, they must be incorporated at 
system generation time. If SYSOUT=B is to 
be used, the unit name SYSCP must be speci- 
fied at system generation time. 


To avoid the repetition of rewriting 
statements and the possibility of error, 
procedures that are used frequently may be 
placed on a system library called the pro- 
cedure library. A procedure contained in 
the procedure library is called a cataloged 

edure A cataloged procedure can be 
called for execution by placing in the 
input stream a simple procedure that may | 
require only the JOB and EXEC statements. 


If slightly modified, the procedure in 
the previous example can be cataloged, 
iee., placed in the procedure library. For 
example, if it were cataloged and given the 
name CATPROC, it could be called for execu- 
tion by placing the following procedure in 
the input stream: 


a ee ee a ee ay a ee ey ee ee ee 1 
|7/JOB1 JOB | 
|//STEP1 EXEC PGM=IEQCBLO0, PARM=DECK | 
|77SYSUT1 DD DSNAME=&UT1, UNIT=SYSDA, SPACE=(TRK, (40) ) 
| “7SYSUT2 DD DSNAME=&§UT2, UNIT=SYSSQ, SPACE=(TRK, (40)) | 
| //SYSUT3 DD DSNAME=€UT3, UNIT=SYSSQ, SPACE=(TRK, (40) ) 
| 77SYSUT4 DD DSNAME=&UT4, UNIT=SYSSQ, SPACE=(TRK, (40) ) | 
|“7SYSPRINT DD SYSOUT=A | 
|/7SYSPUNCH DD SYSOUT=B | 
| /7SYSIN DD * | 
| (source deck) | 
|/* 
J 


Figure 1. Job Control Procedure 


ee ee ee a ee a ee es ee we we ee ae a a we a i i ee 
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47 IOB2 JOB 
//STEPA EXEC PROC=CATPROC 
/7/STEP1.SYSIN DD 3 


(source deck) 
/* 


JOB2 is the name of the job. STEPA is the 
name of the single job step. The EXEC 
statement calls the cataloged procedure 
containing STEP1 to execute the job step 
(PROC=CATPROC). 


The chapters "Using the DD Statement" 
and "A Checklist of Job Control Procedures" 
explain, with numerous examples, the prep- 
aration of job control procedures. The 
chapters "Compiler Data Set Requirements", 
"Linkage Editor Data Set Requirements", and 
"Execution Time Data Set Requirements" 
describe required and optional data sets 
for compilation, linkage editing, and 
execution time job steps. The chapter 
"Cataloged Procedures" provides information 
about using and modifying cataloged proce- 
dures, including three cataloged procedures 
supplied by IBM. 


The following section, "Format of the 
Job Control Statements," shows the format 
and use of the parameters and subparameters 
that can be specified for each job control 
Statement. Some parameters of the state- 
ments are described only briefly. For 
further information, see the publication 
IBM System/360 Operating System: Job Con- 
trol Language, Form C28-6539. The syntact- 
ic format descriptions on the fold-out page 
in this chapter can be used as a reference 
for the exact format and for the use of 
each parameter. 


Job Control Statements 


Indicates a job step and 
describes that job step; 
indicates the load module or 
cataloged procedure to be 
executed 


trols device and volume 
assignment 


I 
input stream from control | 
statements; it must follow | 
each data set that appears in| 
the input stream, e.g., after] 
a COBOL source module punched] 


deck | 


i 
| 
4 
| 
| 
{ 
i 
| 
+ 

DD |Describes data sets, and con- 
i 
i 
4 
| | 
| | 
| | 
| | 
| | 
| | 
| i 
1 


Loose ee 
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FORMAT OF THE JOB CONTROL STATEMENTS 


The COBOL programmer uses the job con- 
trol statements shown in Table 1 to com- 
pile, linkage edit, and execute programs. 


JOB MANAGEMENT 


Job control statements are processed by 
a group of operating system routines known 
collectively as job management. Job mana- 
gement routines interpret control state- 
ments, control the flow of jobs, and issue 
messages to both the operator and the pro- 


grammer. Job management has two major com- 
ponents: a job scheduler and a master 
scheduler. 


The specific facilities available 
through the job scheduler and the master 
scheduler depend on the scheduling level 
the installation selects during system 
generation. Schedulers are available at 
two levels: the sequential scheduler and 
the more powerful priority scheduler. 


Sequential schedulers process job steps 
one at a time in the order of their 
appearance in the input stream. Operating 
systems with a primary control program 
(PCP) use sequential schedulers. 


Priority schedulers process jobs accord- 
ing to their relative priority and avail- 
able system resources. Systems that pro- 
vide multiprogramming (the MFT or MVT 
environments) use priority schedulers. 


CODING JOB CONTROL STATEMENTS 


Job control statements are identified by 
the initial characters // or /* in card 
columns 1 and 2, and may.contain three 
fields -- name, Operation, and operand -- 
plus a possible comments field, as shown: 


[Applicable |controt | 
| Format |Statements | 
}---------------------- 4------------------ { 
{7/7 Name Operation | 
| Operand [Comment] |JOB,EXEC,DD | 
{77 Operation Operand | | 
| {Comment] | EXEC, DD | 
|7* {Comment] | delimiter | 
Sheol Leuestwen acetone J 
Name Field 


The name contains from one through eight 
alphanumeric characters, the first of which 


must be alphabetic. The name begins in 
card column 3. It is followed by one or 
more blanks. The name is used as follows: 


1. To identify the control statement to 
the operating system. 


2. TO enable other control statements in 
the job to refer to information con- 
tained in the named statement. 


3. To relate DD statements to files named 
in a COBOL source program. 


Operation Field 


The operation field is preceded and fol- 
lowed by one or more blanks. It may con- 
tain one of the following operation codes: 


JOB 
EXEC 
DD 


If the statement is a delimiter statement, 
there is no operation field and comments 
may start after one blank. 


Operand Field 


The operand field is preceded and fol- 
lowed by one or more blanks and may con- 
tinue through column 71 and onto one or 
more continuation cards. It contains the 
parameters that give required and optional 
information to the operating system. The 
parameters are separated by commas. A 
blank in the operand field causes the sys- 
tem to treat the remaining data on the card 
aS a comment. There are two types of 
parameters: positional and keyword. 


Positional Parameters: Positional parame- 
ters are the first parameters in the 
operand field, and they must appear in the 
specified order. If a positional parameter 
is omitted and other positional parameters 
follow, the omission must be indicated by a 
comma. If other positional parameters do 
not follow, no comma is needed. 


Keyword Parameters: A keyword parameter 
nay be placed anywhere in the operand field 
Following the positional parameters. A 
<eyword parameter consists of a keyword, 
Followed by an equal sign, followed by a 
single value or a list of subparameters. 

[f there is a subparameter list, it must be 
anclosed in parentheses or single quotation 
narks; the subparameters in the list must 
xe Separated by commas. Keyword parameters 
nay appear in any order. 


amete Subparameters are either 
positional or keyword. Positional and key- 
word subparameters for job control state- 
ments are shown in Figures 2, 3, and 5 on 
the fold-out page. Positional subparame- 
ters appear first in the parameter and must 
be in the specified order. If a positional 
subparameter is omitted and other position- 
al subparameters follow, a comma must indi- 
cate the omission. 


Note: The fold-out page is to be used in 
conjunction with the text for easy 
reference. 


Comments Field 


A comment must be separated from the 
last parameter (or the /* in a delimiter 
statement) by one or more blanks and may 
appear in the remaining columns up to and 
including column 71. A comment may be con- 
tinued onto one or more continuation cards. 
Comments can contain blanks. 


CONVENTIONS FOR CHARACTER DELIMITERS 


Commas, parentheses, and blanks are 
interpreted as character delimiters. If 
they are not intended by the programmer to 
be used as delimiters, the fields in which 
they appear must be enclosed in single quo- 
tation marks, indicating that the enclosed 
information is to be treated as a single 
field. When an apostrophe (or a single 
quotation mark, since the same character is 
used for either) is to be contained within 
such a field, it must be shown as two con- 
secutive single quotation marks (5-8 
punch), not as a double quotation mark (7-8 
punch). For example, 

"WM. O* "CONNOR'S 

This convention applies to three fields: 
programmer's name in the JOB statement, 
information in the PARM parameter of the 
EXEC statement, and accounting information 
in the JOB and EXEC statements. 


RULES FOR CONTINUING JOB CONTROL STATEMENTS 


The operand field or a comment field can 
be continued from one card to another. The 
rules for continuation are: 
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1. Interrupt the operand after a complete 
parameter (after the separating comma 
if another parameter is to follow). A 
comment may be interrupted at any con- 
venient place before column 72. 


2. Insert a nonblank character in column 
72. 


3. Insert slashes in columns 1 and 2 of 
the next card. 


4, Continue the interrupted operand or 
comments in column 16 of that card. 


These same rules apply to subsequent 
continuations if more than one continuation 
card is required. 


JOB_STATEMENT 


The JOB statement (Figure 2) is the 
first statement in the sequence of control 
statements that describe a job. The JOB 
statement contains the following 
information: 


1. Name of the job. 


2. Accounting information relative to the 
job. 


3. Programmer's name. 


4. Indication of whether or not the job 
control statements are to be printed 
on the system output listing. 


5. Conditions for terminating the execu- 
tion of the job. 


6. For priority scheduling systems: job 
priority assignment, job scheduler 
message class, and, for the MVT 
environment, main storage region size. 


7. ‘Parameters specifying checkpoint and 
restart procedures for the entire job. 


jobname 
must always be specified; it identi- 
fies the job to the operating system. 
No two jobs being handled concurrently 
by a priority scheduler should have 
the same jobname. 


account-number and accounting-information 
contain the installation account num- 
ber and any parameters to be passed to 
the installation accounting routines. 
Such routines are written at an 
installation and inserted in the 
operating system when it is generated. 
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programmer-name 
identifies the person responsible for 
the job. 


MSGLEVEL 
indicates the type of control state- 
ment messages the programmer wishes to 
receive from the control program. 


MSGLEVEL=1 
indicates that all control statements, 
as well as control statement errors 
and diagnostic messages, are to be 
listed. 


MSGLEVEL=0 
indicates that only control statement 
errors and diagnostic messages are to 
be listed. This is the default 
condition. 


COND=( (code, operator) [, (code, operator) ]...) 
specifies conditions under which a job 
is to be terminated. Up to eight dif- 
ferent tests, each consisting of a 
code and an operator, may be specified 
to the right of the equal sign. The 
operator indicates the algebraic rela- 
tionship between the code placed in 
the JOB statement and the codes that 
may be issued by each completed job 
step. The code or codes specified are 
compared with the return code at the 
completion of each job step; if any 
condition is met, the remaining steps 
of the job are bypassed. (See the 
COND parameter on the EXEC statement 
for a discussion of the operator 
values and the codes issued by the 
compiler and linkage editor at the end 
of a job step.) 


RD=request 
is used with the PCP or MVT environ- 
ments. This is the restart definition 
parameter. The programmer uses this 
parameter to tell the operating 
system: 


a. whether or not to take checkpoints 
during execution of a program, and 


b. whether or not to restart a pro- 
gram which has been interrupted. 


A checkpoint is taken by periodically 
recording the contents of storage and 
registers during a program's execu- 
tion. The ability to take a check- 
point is provided by the RERUN clause 
in the COBOL language. Checkpoints 
are recorded onto a checkpoint data 
set. In the event of an interruption, 
the programmer may restart his program 
at a checkpoint rather than at the 
beginning of his job step. 


See the RD parameter on the EXEC 
statement for a discussion of the 
forms that RD=request may take. 


RESTART 


is used with the PCP or MVT environ- 
ments. This parameter specifies that 
the program may restart processing at 
a specified point. Restart may occur 
at the beginning of a job step or ata 
checkpoint within a ‘job step. In 
order to restart at a point within a 
job step, a program must previously 
have had a checkpoint record written. 


RESTART=* 


indicates that the restart is to occur 
at the first job step of the job. 


RESTART=stepname 
indicates that restart is to occur at 


the beginning of the job step desig- 
nated in stepname. 


RESTART=(stepname[.procstepname] [, checkid]) 


indicates that restart is to occur at 
the point specified within the job 
step designated by stepname. The sub- 
parameter procstepname is used to 
restart at a point within a cataloged 
procedure. The subparameter checkid 
is used to restart at the checkpoint 
identified by checkid. Checkid is 
expressed as a 1-16 character name 
usually assigned by the operating sys- 
tem at the time a checkpoint is taken. 


Notes: 


e If RESTART is omitted, the program is 


executed from the first job step. 


Generation data sets created and cata- 
loged in steps preceding the restarted 
step must be referred to by subtracting 
one from their generation numbers, 
i.e., generation data set number 0 is 
referred to as -1. 


The PGM and COND parameters of the EXEC 
statement and the SUBALLOC and VOLUME= 

REF parameters of the DD statement can- 
not be used in or following the restart 
job step if they contain values of the 

form stepname or stepname.procstep ref- 
erring to a step preceding the restart 

step. 


PRIORITY SCHEDULING JOB PARAMETERS 


CLASS=jobclass 


assigns a job class to a job. Up to 
three job classes are associated with 
each partition. The term jobclass is 


replaced with an alphabetic character 
A through 0. The use of this paramet- 
er and the meaning of the characters A 
through O are to be determined by each 
installation. If this parameter is 
omitted or CLASS A is specified, the 
default job class of A is assigned to 
the job. 


PRTY=job priority 
assigns other than the standard job 
priority established by an installa- 
tion; job priority is expressed as a 
decimal number from 0 through 14. 


Whenever possible, priority 13 should be 
avoided. This is used by the system to 
expedite processing of exceptional jobs. 

It is also intended for other special uses 
by future features of systems with priority 
schedulers. If this parameter is omitted, 
the standard job priority is assigned to 
the job. 


MSGCLASS=classname 
specifies an output class, other than 
the standard class A, to which all 
messages issued by the job scheduler 
are routed. An output writer assigned 
to the output class transfers this 
data to a specific device. Classname 
is expressed as either an alphabetic 
(A through Z) or numeric (0 through 9) 
character. If this parameter is 
omitted or is coded MSGCLASS=A, job 
scheduler messages are routed to the 
standard output class A. 


TYPRUN=HOLD 
temporarily prevents a job from being 
selected for processing. When this is 
specified, the job is held until a 
RELEASE command is issued by the 
operator. TYPRUN=HOLD is particularly 
useful when one job must be run after 
another job has terminated. 


REGION=nnnnnk 
is used with the MVT environment only. 
This parameter specifies the size of 
the main storage region to be allo- 
cated to a job that requires an unusu- 
al amount of main storage. The symbol 
nnnnn represents the number, in 
decimal, of 1024-byte areas to be 
allocated to the job, e.g., REGION= 
52K. This number must take into 
account the storage requirements of 
resident control functions and cannot 
exceed 16,384. It should be specified 
as an even number. (If specified as 
an odd number, the system treats it as 
the next highest even number.) If 
this parameter is omitted, a default 
region size is allocated. 
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For additional information on the REGION 
parameter see the chapter “Machine 
Considerations." 


Note: If different region sizes for each 
step in the job are desired, the REGION 
parameter in the EXEC statement associated 
with each step can be coded instead (see 
"EXEC Statement"). 


ROLL=(x, y) 
is used with the MVT environment only. 
This parameter allocates additional 
main storage to a job step whose own 
region does not contain any more 
available space. In order to allocate 
this additional space to a job step, 
another job step may have to be rolled 
out, i.e., temporarily transferred to 
secondary storage. When x is replaced 
with YES, each of the programmer's job 
steps can be rolled out; when x is 
replaced with NO, the job steps cannot 
be rolled out. When y is replaced 
with YES, this indicates that each job 
step can cause rollout; when y is 
replaced with, NO, the job steps cannot 
cause rollout. (If additional main 
storage is required for the job's 
steps, YES must be specified for y.) 
If this parameter is omitted, 
ROLL=(YES,NO) is assumed. ROLL 
parameters can also be coded in EXEC 
statements, but are superseded by a 
ROLL parameter coded in the JOB 
statement. 


EXEC STATEMENT 


The EXEC statement (Figure 3) defines a 
job step and calls for execution. It con- 
tains the following information: 


The name of a load module or the name 
of a cataloged procedure that contains 
the name of a load module that is to 
be executed. The load module can be 
the COBOL (F) compiler, the linkage 
editor, or any COBOL (F) program in 
load module form. 


1. 


2 Accounting information for this job 


step. 
3. Conditions for bypassing the execution 
of this job step. 
4. For priority scheduling systems: com- 
puting time for a job step or cata- 
loged procedure step, and main storage 
region size. 
5. Compiler or linkage editor options 
chosen for the job step. 
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6. Parameters specifying checkpoint and 
restart procedures for the job step. 
Note: If the information specified is 





normally delimited by parentheses, but con- 
tains blanks, parentheses, or equal signs, 
it must be delimited by single quotation 
marks instead of parentheses. 


stepname 
is the name of the job step. It is 
required when information from this 
control statement is to be referred to 
in a later job step. 


PGM= 
specifies the program to be executed 
in the job step. 


Specifying the Compiler: 


PGM=IEQCBLOO 

indicates that the COBOL (F) compiler 
is the processing program to be 
executed in the job step. 


Specifying the Linkage Editor: 


PGM=IEWL 

indicates that the linkage editor is 
the processing program to be executed 
in the job step. 


Specifying a Load Module: 


PGM=progname 

indicates that some other program is 
to be executed, normally a COBOL pro- 
gram that is in load module format. 


PGM=*. stepname. ddname 
specifies a load module defined as a 
data set in a DD statement of a pre- 
vious job step. The * indicates the 
current job; stepname is the name of 
the previous job step that refers to 
the program; and ddname is the ddname 
of the DD statement within the pre- 
vious job step that defines the load 
module. The job step referred to must 
be in the same job. 


This form is used, for example, 
when the previous job step is the 
linkage editor and the output from the 
linkage editor is the load module that 
is to be executed in this job step. 


PROC=procname 

procname 
indicates that a cataloged procedure 
is to be called. The procname is the 
unqualified name of the cataloged pro- 
cedure (see “Using the DD Statement" 
for a discussion of qualified names). 


PGM=* 


AcCT= 


ACCT. 


COND 
COND. 


«stepname. procstep. ddname 

indicates that the name of the program 
to be executed is to be taken from a 
DD statement of a cataloged procedure 
that has been previously called within 
the job. The * indicates the current 
job; stepname is the name of the job 
step that called the cataloged proce- 
dure; procstep is the name of a step 
within the procedure; ddname is the 
name of a DD statement within the pro- 
cedure step. (The stepname cannot 
refer to a job step in another job.) 


(accounting information) 

specifies accounting information to 
the installation accounting routines 
for this job step. 


If both the JOB and EXEC statements 
contain accounting information, the 
installation accounting routines 
decide how the accounting information 
shall be used for the job step. 


procstep=(accounting information) 

is used to pass accounting information 
to a step within a cataloged 
procedure. 


A maximum of 142 characters may be 
written between the parentheses or 
single quotation marks that enclose 
the list of options. 


eas) 

states conditions, depending upon 
return codes issued by preceding job 
steps, under which the current step or 
steps within a cataloged procedure are 
to be bypassed. If any of the condi- 
tions are met, the job step is 
bypassed. For a COBOL programmer, the 
return codes are from a compilation or 
linkage editor job step, since a COBOL 
program itself cannot generate the 
return codes. 


Bypassing the Current Job Step 
COND={( (code, operator [,stepname])...) 


The stepname identifies the previously 
executed job step that issued the 
return code to be tested. If stepname 
is not specified, code is compared to 
the return codes issued by all preced- 
ing steps in the job. 


ee ee ee ee 


COND. procstep=( (code, operator [stepname 
{.procstep]])...) 
If the job step calls for execution of 


a cataloged procedure, the COND param- 
eter (without the procstep quali- 
fication) replaces all COND parameters 
in each step of the procedure. The. 
COND. procstep parameter applies to a 
job step contained within the cata- 
loged procedure; procstep identifies 
this procedure step. This parameter 
replaces the entire COND parameter in 
the procedure step. It may be 
repeated in the EXEC statement once 
for each step in the cataloged 
procedure. 


Note the difference between proc- 
step in COND.procstep and stepname. 
The procstep identifies the job step 
that may or may not be bypassed. The 
stepname identifies the previously 
executed job step that issued the 
return code to be tested. If the 
return code of a step in a cataloged 
procedure is to be tested, the proce- 
dure stepname must be qualified by the 
name of the step that called for 
execution of the procedure (i.e., 
stepname. procstep). If stepname is 
not specified, the code is compared 
with the return codes issued by all 
preceding steps in the job. 


code 
a number, specified by the programmer, 
to be compared with the job step 
return code. 

operator 


specifies the test to be made of the 
relation between the programmer- 
specified code and the job step return 
code. It is similar to the relation 
test written in a COBOL IF statement; 
that is, it is interpreted as "if 
programmer-specified code is (opera- 
tor) ‘stepname' return code, then the 
current job step is to be bypassed." 
There are six operators: 


Operator Meaning 

GT greater than 

GE greater than or equal to 
EQ equal to 

NE not equal to 

LT less than 

LE less than or equal to 


As many as eight conditions to be 
tested may be specified in either form 
of the COND parameter. 


The return codes for both the compiler 
and linkage editor are: 
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00 Normal conclusion. 

04 Warning messages have been listed, 
but program is executable. 

08 Error messages have been listed; 
execution may fail. 

12 Severe errors have occurred; 
execution is impossible. 

16 Terminal errors have occurred; 
execution of the processor has 
been terminated. 


The compiler issues a return code of 16 
when: 


e BASIS member-name is specified and 
no member of that name is found, or 


e COPY member-name is specified and no 
SYSLIB statement is included, or 


e Not enough core storage is available 
for the tables required for 
compilation. 


The return codes have a correlation 
with the severity level of the error 
messages. With linkage editor, for 
example, the rightmost digit of the 
message number states the severity 
level; this number is multiplied by 4 
to get the appropriate return code. 
With the COBOL compiler, 04 to 16 are 
equal to the severity codes W, Cc, E 
and D, respectively. 


RD[{.procstepname]=request 
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is used with the PCP or MVT environ- 
ments. This is the restart definition 
parameter. The programmer uses this 
parameter to tell the operating 
system: 


ae whether or not to take checkpoints 
during execution of a job step, 
and 


be whether or not to restart a job 
step which has been interrupted. 


A checkpoint is taken by periodically 
recording the contents of storage and 
registers during a program's execu- 
tion. The ability to take a check- 
point is provided by the RERUN clause 
in the COBOL language. Checkpoints 
are recorded onto a checkpoint data 
set. In the event of an interruption, 
the programmer may restart his program 
at a checkpoint rather than at the 
beginning of his job step. 


Request may take one of the following 
forms: 


R (Restart) 
to indicate that an automatic 
restart is to occur as soon as an 
interrupt terminates processing. 
Restart will occur at the latest 
checkpoint taken. In order to 
take checkpoints, the programmer 
must specify at least one RERUN 
clause in his program. 


RNC (Restart, No Checkpoint) 
to indicate an automatic restart 
may occur only at the beginning of 
a job step. No checkpoints are 
taken; no RERUN clause in the 
COBOL program is necessary. 


NR (No Restart) 
to indicate that no restart is to 
occur in the event of an inter- 
rupt. Checkpoints may still be 
taken during the course of the 
program's execution in the event 
the programmer may want to restart 
his program at a later time. The 
programmer must specify at least 
one RERUN clause in order to take 
checkpoints. 


NC (No Checkpoint) 
to indicate that no restart is to 
occur and no checkpoint is to be 
taken. No RERUN clause is 
necessary. 


Notes: 


e If the RD parameter is omitted, the 
following action occurs: if no che- 
ckpoints were taken before an inter- 
ruption, the program cannot restart; 
if checkpoints were taken, then 
automatic restart will occur in the 
event of an interruption. 


e If no RERUN clause is specified in 
the user's program, no checkpoints 
are written, regardless of the dis- 
position of the RD parameter. 


e Systems operating under the MVT 
environment must also specify the 
MSGLEVEL=1 parameter in the JOB sta- 
tement if the RD parameter indicates 
a restart option. 


e If RD is coded on the JOB statement, 
it will override all RD parameters 
on any EXEC statement. 


e The programmer may use the form RD. 
procstepname to restart at a proce- 
dure step within a cataloged proce- 
dure. The programmer may code as 
many parameters of this form as 
there are steps in the cataloged 
procedure. 


Note: A COBOL load module cannot generate 
a return code. 





PARM=(option[, option]...) 
passes options (Figure 4 on the fold- 
out page) to the compiler or linkage 
editor when either is called by the 
PGM parameter in the EXEC statement or 
to the first step in a cataloged 
procedure. 


PARM. procstep=(option[, option]...) 

passes options to a compiler or link- 
age editor step within the named cata- 
loged procedure step. Any PARM param- 
eter already appearing in the proce- 
dure step is deleted, and the PARM pa- 
rameter that is passed to the proce- 
dure step is inserted. 


A maximum of 40 characters may be writ- 
ten between the parentheses or single quo- 
tation marks that enclose the list of 
options. The compiler selects the valid 
options of the PARM field for processing by 
looking for three significant characters of 
each key option word. When the keyword is 
identified, it is checked for the presence 
or absence of NO, as appropriate. The pro- 
grammer can make the most efficient use of 
the option field by using the significant 
characters instead of the entire option. 
The following table lists the significant 
characters for each option (for an explana- 
tion of each option see "Options for the 
Compiler" below): 


Bg Rac aera a Toco oe ee 1 
| | Significant | 
| Option | Characters | 
}------------------ }--------------------- -4 
COPY | COP | 
BASIS BAS { 
| LINECNT | CNT i 
| SEQ | SEQ | 
| FLAGE (W) | LAG, LAGW 
j SIZE | SIZ i 
| BUF BUF | 
| SOURCE | SOU 
| MAP | MAP | 
i DECK | DEC { 
| LOAD | LOA | 
SPACE | ACE 
| DMAP | DMA \ 
| PMAP | PMA \ 
SUPMAP SUP } 
| CLIST CLI 
[si ae em me me PET Os sie te Se J 


OPTIONS FOR THE COMPILER 


The default options indicated by an 
underscore in the following discussion can 
be changed within each installation at sys- 
tem generation time. The format of the 
PARM parameter is illustrated in Figure 4. 


Note: When a subparameter contains an 
equal sign, the entire information field of 
the PARM parameter must be enclosed by 
Single quotation marks instead of paren- 
theses (e.g., PARM='SIZE=160000,MAP'). 


SIZE-yyyyyyy 
indicates the amount of main storage, 


in bytes, available for compilation 
(see “Machine Considerations"). 


BUF=yyyyyy 
indicates the amount of main storage 


to be allocated to buffers. If both 
SIZE and BUF are specified, the amount 
allocated to buffers is included in 
the amount of main storage available 
for compilation (see Appendix D for 
information about how buffer size is 
determined). 


SQURCE \ 
NOSOURCE 
indicates whether or not the source 


module is to be listed. 


CLIST 

\noectairt 
indicates whether or not a condensed 

. listing is to be produced. If speci- 

fied, the procedure portion of the 
listing will contain only the source 
card number, location of the first 
generated instruction, and EBCDIC verb 
name for each verb. 


MAP 

{NOMAP 
indicates whether or not a glossary, 
global tables, object code listing, 
and assembler language expansion of 
the source module are to be listed. 


DMAP 
NODMAP 


indicates whether or not a glossary is 
to be listed. 


fee 
nopMapy 
indicates whether or not global tables 

and assembler language expansion of 


the source modules are to be listed. 


Note: PMAP and DMAP taken together 
are the equivalent of MAP. If the 
user wants both PMAP and DMAP, he can 
specify MAP in the PARM parameter. If 
he wants only PMAP, he can specify 
either PMAP or NODMAP. If a conflict 
exists in the PARM parameter, the last 
encountered option will be selected. 
For example, NODMAP followed by MAP 
results in the selection of both PMAP 
and DMAP. MAP followed by NODMAP 
results in the selection of PMAP only. 


Job Control Procedures 21 


{LOAD \ 

NOLOAD 
indicates whether or not the object 
module is to be placed in a direct- 
access or a tape volume so that the 
module can be used as input to the 
linkage editor. If option is used, a 
SYSLIN DD statement must be specified. 


DECK 

{nobEcx} 
indicates whether or not the object 
module is to be punched. If the DECK 
option is used, a SYSPUNCH DD state- 
ment must be specified. 

| 

NOSEQ 


indicates whether or not the compiler 
is to check the sequence of the source 
module statements. If the statements 
are not in sequence, a message is 
printed. 


LINECNT=nn 

indicates the number of lines to be 
printed on each page of the compila- 
tion output listing. The number spec- 
ified by nn must be a 2-digit integer 
from 01 to 99. If the LINECNT option 
is omitted, 60 lines are printed on 
each page of the output listing. 


FLAGW 
FLAGE 


indicates the type of messages that 
are to be listed for the compilation. 
FLAGW indicates that all warning and 
diagnostic messages are to be listed. 
FLAGE indicates that all diagnostic 
messages are to be listed, but the 
warning messages are not to be listed. 


{ SUPMAP 

\Hosuenay 
indicates whether or not the object 
code listing, and object module and 
linkage editor decks are to be sup- 
pressed if an E (or D) level message 
is generated by the compiler. 


Janets \ 

NOBASIS 
indicates whether or not a BASIS card 
may be present in the source module 
that is to be compiled. BASIS speci- 
fies that a BASIS card may be in the 
source module. NOBASIS specifies that 
no. BASIS statement is in the source 
module. This option is used to opti- 
mize buffer allocation at compilation 
time. 


COPY 
NOCOPY 
indicates whether or not a COPY or 


INCLUDE statement may be in the source 
module. COPY specifies that one or 
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both may appear. NOCOPY specifies 
that no INCLUDE or COPY statements are 
in the source module. This option is 
used to optimize buffer allocation at 
compilation time. 


SPACE1 

SPACE2 

SPACE3 
indicates what type of spacing is to 
be used on the listing that is 


generated when SOURCE is specified. 
SPACE1 specifies single spacing, 


SPACE2 specifies double spacing, and 
SPACE3 specifies triple spacing. 

For examples of what the SOURCE, MAP, 
DECK, and SEQ options produce, refer to 
"Output." 

OPTIONS FOR THE LINKAGE EDITOR 

MAP 
indicates that a map of the load 
module is to be listed. If MAP is 


specified, XREF cannot be specified, 
but both can be omitted. 


XREF 
indicates that a cross reference list 
and a module map is to be listed. If 
XREF is specified, MAP cannot be 
specified. 


LIst 
indicates that any linkage editor con- 
trol statements associated with the 
job step are to be listed. 


OVLY 
indicates that the load module is to 
be in the format of an overlay 
structure. 


The format of the PARM parameter is 
illustrated in Figure 4 For examples of 
what the MAP, XREF, and LIST options pro- 
duce, refer to the chapter "Output." Link- 
age editor control statements and overlay 
structures are explained in the chapter 
"Calling and Called Programs." There are 
other PARM options for linkage editor proc- 
essing that describe additional processing 
options and special attributes of the load 
module (see the publication IBM System/360 


Operating System: Linkage Editor, Form 
C28-6538). 


PRIORITY SCHEDULING SYSTEM PARAMETERS 


TIME= (minutes, seconds) 


assigns a limit to the computing time 
used by a single job step, a cataloged 
procedure, or a cataloged procedure 
step (see “Notes" below). Such an 
assignment is useful in a multipro- 
gramming environment where more than 
one job has access to the computing 
system. The terms minutes and seconds 
represent the maximum number of 
minutes and seconds allotted for 
execution of the job step. 


Notes: 


e If the job step requires use of the 
system for 24 hours (1440 minutes) 
or longer, the programmer should 
specify TIME=1440. Using this numb- 
er suppresses timing. The number of 
seconds cannot exceed 59. 


e If the time limit is given in 
minutes only, the parentheses need 
not be coded; e.g, TIME=5. 


e If the time limit is given in 
seconds, the comma must be coded to 
indicate the absence of minutes; 
Cees TIME=(, 45). 


e When the job step uses a cataloged 
procedure, a time limit for a single 
procedure step can be set by quali- 
fying the key word TIME with the 
procedure step name; i.e., TIME. 
procstep=(minutes,seconds). This 
specification overrides the TIME pa- 
rameter in the named procedure step 
if one is present. As many parame- 
ters of this form can be coded as 
there are steps in the cataloged 
procedure. 


e To set a time limit for an entire 
procedure, the TIME key word is left 
unqualified. This specification 
overrides all TIME parameters in the 
procedure if any are present. 


If this parameter is omitted, the stan- 
dard job step time limit is assigned. 


REGION=nnnnnk (MVT only) 


specifies the size of the main storage 
region to be allocated to the asso- 
ciated job step, for jobs that require 
an unusually large amount of main 
storage. The symbol nnnnn represents 
the number, in decimal, of 1024-byte 
areas to be allocated to the job step; 
@.ge, REGION=52K. This number must 
take into account the storage require- 
ments of resident control functions 


and cannot exceed 16,384K bytes. It 
should be specified as an even number. 
(If specified as an odd number, the 
system treats it as the next highest 
even number. ) 


Notes: 


e If a REGION parameter has been spe- 
cified in the JOB statement, REGION 
parameters in the job's EXEC state- 
ments are ignored. 


e When a job step uses a cataloged 
procedure, a region size for a 
single procedure step can be 
requested by qualifying the REGION 
parameter with the procedure step- 
name, i.e¢., REGION. procstep=nnnnnk. 
This specification overrides the 
REGION parameter in the named proce- 
dure step if one is present. As 
Many parameters of this form can be 
coded as there are steps in the 
cataloged procedure. 


e To request a single region size for 
an entire cataloged procedure, the 
REGION parameter is left unquali- 
fied. This specification overrides 
all REGION parameters in the proce- 
dure, if any are present. 


If this parameter is omitted, a default 
region size is allocated. 


ROLL= (x, y) 


is used for priority scheduling sys- 
tems only. This parameter allocates 
additional main storage to a job step 
whose own region does not contain any 
more available space. In order to 
allocate this additional space to a 
job step, another job step may have to 
be rolled out, i.e., temporarily 
transferred to secondary storage. 
When x is replaced with YES, the job 
step can be rolled out; when x is 
replaced with NO, the job step cannot 
be rolled out. When y is replaced 
with YES, the job step can cause rol- 
lout; when y is replaced with NO, the 
job step cannot cause rollout. (If 
additional main storage is required 
for the. job step, YES must be speci- 
fied for y.) If this parameter is 
omitted, ROLL=(YES,NO) is assumed. 


e If the ROLL parameter is specified 
in the JOB statement, the ROLL pa- 
rameter in the EXEC statements is 
ignored. 


e When a job step uses a cataloged 


procedure, it can be indicated 
whether or not a single procedure 
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step has the ability to be rolled 
out and to cause rollout of another 
job step. To indicate this the 
procedure stepname, i.e., ROLL. 
procstepname, is included as part of 
the ROLL parameter. This specifica- 
tion overrides the ROLL parameter in 
the named procedure step, if one is 
present. AS many parameters of this 
form can be coded as there are steps 
in the cataloged procedure. 


To indicate whether or not all of 
the steps of a cataloged procedure 
have the ability to be rolled out 
and to cause rollout of other ‘job 
steps, the ROLL parameter can be 
coded without a procedure stepname. 
This specification overrides all 
ROLL parameters in the procedure, if 
any are present. 


DD_STATEMENT 


The data definition (DD) statement 
(Figure 5) identifies each data set that is 
to be used in a job step, and it furnishes 
information about the data set. The DD 
statement specifies input/output facilities 
required for use of the data set; it also 
establishes a logical relationship between 
the data set and input/output references in 
the program named in the EXEC statement for 
the job step. 


Parameters used most frequently for 


COBOL programs are discussed in detail. 


The other parameters (e.g., SEP and AFF) 
are mentioned briefly. For further infor- 
Qperating System: Job Control Language, 
Form C28-6539. 


NOTATION FOR DESCRIBING JOB CONTROL 

STATEMENTS 3.  Upper-case letters and words, numbers, 
and the set of symbols listed below 
are written in an actual control 


The notation used in this publication to statement exactly as shown in the 
define the syntax of job control statements statement definition. (Any exceptions 
is as follows: to this rule are noted in the defini- 


tion of a control statement.) 


1. The set of symbols below define con- 
trol statements, but they are never 


[COND=((code, operator) [, (code, operator) ]...°)7] 
(RD=request] 


written in an actual statement. single quotation mark : 
asterisk * 
hyphen > joins lower-case let- comma ; 
ters, words, and sym- equal sign = 
bols to form a single parentheses ( ) 
variable period , 
or symbol | indicates alternatives slash / 
braces { } indicate a group of 
related items, only 
one of which is re- 4. An underscore indicates a default 
quired option. If an underscored alternative 
brackets {J indicate optional items. is selected, it need not be written in 
Brackets are also used the actual statement. 
with alternatives to 
indicate that a 
default is assumed if Note: Many of these defaults can be 
no alternative is changed at system generation time. 
listed 
ellipsis eres indicates that the pre- 
ceding item or group 5. Lower-case letters, words, and symbols 
of items can be appearing in a control statement 
repeated definition represent variables for 
super- 1 indicates a footnote which specific information is substi- 
script tuted in the actual statement. 

2. Stacked items, enclosed in either 6. Blanks are used in the figures on the 
brackets or braces, represent alterna- fold-out page to improve the readabil- 
tive items. No more than one of the ity of control statement definitions. 
stacked items can be written by the In actual statements, blanks would be 
programmer. interpreted as delimiters. 

| at adie aac ares a, atta rataad yn pt a aa aa aaa a aa a a Ea a a a 1 
| Name |Operation|Operand | 
p--~------ ae Sa aaa { 
| l Positional Parameters 
| | 
//jobname | JOB { ((fLaccount-number] [,accounting-information])1+ 2 3] 
| 
|, programmer-name]* 5 
Keyword Parameters 
] 
| | MSGLEVEL=1 
{ | MSGLEVEL=0 
i 
| 
| 
| 
| 
| 
| 
| 


* 
reson | Stepname procstepname) \ 
(stepnamel.procstepname] [, checkid] ) 
| (PRTY=job priority] 
| {MSGCLASS=classname] 
| (REGION=nnnnnk) 
| (ROLL=x, y) J 
| (TYPRUN=HOLD] 
ee Loco Ssls Poe So ee eee See See ee eee See Se ee ee eee ee eee | 
1If the information specified (account-number and/or accounting-information) contains | 
blanks, parentheses, or equal signs, the information must be delimited by single quo-| 
tation marks instead of parentheses. 
2If only account-number is specified, the delimiting parentheses may be omitted. | 
3The maximum number of characters allowed between the delimiting quotation marks is | 
144, | 
“If programmer-name contains commas, parentheses, apostrophes, or blanks, it must be | 
enclosed within single quotation marks. | 
| 
| 
| 
4 


| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
: 
([CLASS=jobclass] | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 


Se ES Se ED I ee RE ce ee ee eS 


The maximum number of characters allowed for programmer-name is 20. 
6The maximum number of repetitions allowed is 7. 
7If only one test is specified, the outer pair of parentheses may be omitted. 


SS a ee a mee a le ES ce SS Sa Se eS ee ee ee LE me ee eS ce 


e Figure 2. JOB Statement 
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VOLUME=({PRIVATE], [RETAIN], [volume sequence number], [volume count] 


Keyword Subparameters 


+ SER= (volume-serial-number [volume-serial-number] 9...) 


dsname ) 
a REF= *.ddname 

*.stepname.ddname 

*,stepname. procstep. ddname 


NL 
LABEL=( [data-set-sequence-number], 2 
NSL 


, EXPDT=yyddd ) 
« RETPD=xxxx 


NEW , DELETE 
OLD KEEP 
DISP= ( SHR , PASS ) 
MOD , CATLG 
, UNCATLG 


SYSOUT=classname 
SYSOUT=(x[, program-—name] [, form-no. }) 


1The name field must be blank when concatenating data sets. | 
2All parameters are optional to allow a programmer flexibility in the use of the DD | 
statement; however, a DD statement with a blank operand field is meaningless. | 
3If the positional parameter is specified, keyword parameters cannot be specified. | 
“If subparameter-list consists of only one subparameter and no leading comma (indicat- | 
ing the omission of a positional subparameter) is required, the delimiting paren- | 
theses may be omitted. | 
SIf subparameter~list is omitted, the entire parameter must be omitted. | 
S6See User Defined Files for the applicable subparameters. | 
7See the publication IBM System/360 Operating System: Job Control Language, Form | 
C28-6539. | 
SIf only name is specified, the delimiting parentheses may be omitted. | 
°If only one volume-serial-number is specified, the delimiting parentheses may be | 
omitted. | 
1°The SEP and AFF parameters should not be confused with the SEP and AFF subparameters | 
of the UNIT parameter. | 


‘igure 5. The DD Statement (Part 2 of 2) 
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Cea iat sar Sea aieauarex nen Sd CS a a a a aa 1 
| 


tstepname is required when information from this control statement is referred to in a] 
later job step. 
2If this format is selected, it may be repeated in the EXEC statement once for each | 
step in the cataloged procedure. | 
3If the information specified contains any special characters except hyphens, it must | 
be delimited by single quotation marks instead of parentheses. | 
“Tf accounting-information contains any special characters except hyphens, it must be | 
delimited by single quotation marks instead of parentheses. | 
SThe maximum number of characters allowed between the delimiting quotation marks or | 
parentheses is 142. | 
6The maximum number of repetitions allowed is 7. | 
7If only one test is specified, the outer pair of parentheses may be omitted. | 
8If the only special character contained in the value is a comma, the value may be en-]| 
closed in parentheses or in quotation marks; otherwise, special characters are en- | 
closed in quotation marks. | 
°The maximum number of characters allowed between the delimiting quotation marks or | 
parentheses is 40. | 


1 
| Name | Operation Operand | 
}-~----------- $--------- fo------------------------------ +--+ ----- === == === === -- === == == : 
| ! | Positional Parameters | 
| ] | | 
{77 [stepname]1] EXEC ] PGM=progname | 
i | | PGM=*,. stepname. ddname | 
| | { PROC=procname | 
| | | |procname | 
| } | PGM=*, stepname. procstep. ddname. | 
| | | | 
| | | Keyword Parameters | 
1 | 1 | 
| ] | ACCT2 3°64 5 | 
| 1 | ACCT. procstepjf= (accounting-information) | 
| | | | 
| | | Jenne: 6 7 | 
| | | COND. procstepj= ((code, operator[,stepname[. procstep]])...){ | 
| | | | 
l j | {RD[. procstepname]=request] | 
| l | | 
| | | PARM2 38 9 | 
| | | PARM. procstepj= (option[,option]..) | 
| | | | 
| ] | eee | 
| l l TIME. procstepf= (minutes, seconds) | 
| | | | 
l | | REGION | 
{ | | REGION. procstep = nnnnnk | 
| l | | 
| | | ees | 
| | | ROLL. procstepf= (x,y) | 
[-—----~~--—--— eo eS Wes oe ee he Sak ee ee a ee es Se ee eels 4 
| 
| 
1 
| 
| 
| 
| 
| 
| 
l 
| 
| 
| 
1 
| 
| 
l 


Figure 3. EXEC Statement 


Pe SS ST SA SS SS SL A A SS A AL a SNS SS A SS a eS SS <P San Sa <a ane cs a me a ce ee co ee SO ee ee ee ce ee a ee ee ee ee 


c 
]|Compiler: 





Linkage Editor: 


MAP 
PARM =(| XREF!] (,LIST] [,OvLY] ) 


LS SF TA SS A SS SS SS aS a ee ee a ce ca ee co Ae me nt ae a cam ce a ae a a es se i re a ee ce ae ee ee ee 


: 
| 
| SOURCE MAP DMAP PMAP SUPMAP | 
ee eee {,BUF=yyyyyy] | ,»NOSOURCE| |,NOMAP | |,NODMAP| |,NOPMAP | | ,NOSUPMAP | | 
| 
] LOAD DECK SEQ CLIST | 
| » NOLOAD « NODECK » NOSEQ {, LINECNT=nn] , NOCLIST | 
| ODECK NOCLIST 
| 
i FLAGW BASIS COPY SPACE1 | 
| , FLAGE , NOBASIS| |, NOCOPY| | SPACE2 y2 23 | 
| , SPACE3 | 
l | 
| | 
| | 
| | 
5 


{+If the information specified contains any special characters, it must be delimited by | 
| Single quotation marks instead of parentheses. | 
{2If£f the only special character contained in the value is a comma, the value may be en- | 
| closed in parentheses or quotation marks. | 
}*The maximum number of characters allowed between the delimiting quotation marks or | 
] parentheses is 40. | 
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a ae te EY A ce ge SS cee ee a ee ee ee ee ee ee a re ee ee eae 


T T 
{ Name | Operation | 
SS te a entree Jo oa 4----~---.. 
{ ddname a | DD | 
| {77 |procstep. ddname | { 
erate ae omoa ea eee 5 AOR nae ea anny ire RR A heehee ee een ee 
pee ee Sas oe ee a ee ee ee 
| Operand? 


Positional Parameters 


* 3 
DATA 
DUMMY 


Keyword Parameters “% § 
(DDNAME=ddname] 


ae ee ee ee oe ee ee oe 


dsname 
dsname (element) 
*,.ddname 
DSNAME= *,. stepname. ddname 
*, stepname. procstep. ddname 
éname 
&name (element) 


dsname 

DCB=( | *.ddname (, subparameter-list] ) 
*, stepname. ddname 
*,stepname. procstep. ddname 


SEP=(subparameter list)| 7 10 
AFF=ddname 


Positional Subparameters Keyword Subparameters 


ere a [,SEP=(list of up to 8 ddnames) ]) a 
UNIT= (AFF=ddname) 


Positional Subparameters 


TRK 
seace=(\ » (primary-quantity[,secondary-quantityl], 
average-record-length 
, MXLG . 
{directory- or index-quantity])[,RLSE] , ALX {, round] ) 
, CONTIG 


SPACE=(ABSTR, (quantity, beginning-address[,directory or index quantity])) 


CYL 

SPLIT=(n, hae tbe iaseyahantey adsense ea) 
TRK 

SUBALLOC= ( CYL , (primary-quantityl[, secondary-quantity] 
average-record-length 


eS ee ee Se ee re ES ee re cane ee ee es ee gee ee eee SS DS SS SU aoe eS TS gS OEE GO Ge ee SD ee eee eee ee eee ees ee eee ee ee ee ee 


ddname 
{, directory-quantity]) , stepname. ddname ) 
{ stepname. procstep. ddname 


e Figure 5. The DD Statement (Part 1 of 2) 


28 


VOLUME=({PRIVATE], [RETAIN], [volume sequence number], [volume count] 


Keyword Subparameters 


+ SER= (volume-serial-number [volume-serial-number] 9...) 


dsname ) 
a REF= *.ddname 

*.stepname.ddname 

*,stepname. procstep. ddname 


NL 
LABEL=( [data-set-sequence-number], 2 
NSL 


, EXPDT=yyddd ) 
« RETPD=xxxx 


NEW , DELETE 
OLD KEEP 
DISP= ( SHR , PASS ) 
MOD , CATLG 
, UNCATLG 


SYSOUT=classname 
SYSOUT=(x[, program-—name] [, form-no. }) 


1The name field must be blank when concatenating data sets. | 
2All parameters are optional to allow a programmer flexibility in the use of the DD | 
statement; however, a DD statement with a blank operand field is meaningless. | 
3If the positional parameter is specified, keyword parameters cannot be specified. | 
“If subparameter-list consists of only one subparameter and no leading comma (indicat- | 
ing the omission of a positional subparameter) is required, the delimiting paren- | 
theses may be omitted. | 
SIf subparameter~list is omitted, the entire parameter must be omitted. | 
S6See User Defined Files for the applicable subparameters. | 
7See the publication IBM System/360 Operating System: Job Control Language, Form | 
C28-6539. | 
SIf only name is specified, the delimiting parentheses may be omitted. | 
°If only one volume-serial-number is specified, the delimiting parentheses may be | 
omitted. | 
1°The SEP and AFF parameters should not be confused with the SEP and AFF subparameters | 
of the UNIT parameter. | 


‘igure 5. The DD Statement (Part 2 of 2) 
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Name_Field 


ddname 


is used: 


e to identify data sets defined by 
this DD statement to the compiler 
or linkage editor (see "Compiler 
Data Set Requirements" and "Link- 
age Editor Data Set Require- 
ments"), or 


e to relate the data sets defined in 
this DD statement to a file 
described in a COBOL source pro- 
gram (see "User-Defined Files"), 
and 


e to identify this DD statement to 
other control statements in the 
input stream. 


procstep. ddname 


is used to alter or add DD statements 
in cataloged procedures. The step in 
the cataloged procedure is identified 
by procstep. The ddname identifies 
either: 


e A DD statement in the cataloged 
procedure that is to be modified 
by the DD statement in the input 
stream, or 


e A DD statement that is to be added 
to the DD statement in the proce- 
dure step. 


Operand Field 


DATA 
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indicates that data immediately fol- 
lows this DD statement in the input 
stream. This parameter is used to 
specify a source deck or data in the 
input stream. If the EXEC statement 
specifies execution of a program, only 
one data set may be placed in the 
input stream. The end of the data set 
must be indicated by a delimiter 
statement. The data cannot contain // 
or /* in the first two characters of 
any record. The DD * statement must 
be the last DD statement of the job 
step. In MVT, for a step with a 
Single input stream data set, DD * and 
a /* statement are not required. The 
system will supply both if missing. 
The default DDNAME will be SYSIN. 


also indicates data in the input 
Stream. The restrictions and use of 
the DATA parameter are the same as for 
the asterisk, except that // may 
appear in the first and second posi- 


tions in the record, for example, when 
the data consists of control state- 
ments of a procedure that is to be 
cataloged. 


DUMMY 


allows the user's processing program 
to operate without performing input/ 
output operations on the data set. 
The DUMMY parameter is valid only for 
data sets that are referred to by the 
basic sequential or queued sequential 
file processing techniques. If the 
DUMMY parameter is specified, a read 
request results in an end of data set 
exit giving unpredictable results. A 
write request is recognized, but no 
data is transmitted. No device allo- 
cation, external storage allocation, 
Or cataloging takes place for dummy 
data sets. 


defines a pseudo data set that will 
assume the characteristics of a real 
data set if a subsequent DD statement 
of the step is labeled with the speci- 
fied ddname. When the DDNAME parame- 
ter is specified, it must be the first 
parameter in the operand. All other 
parameters are ignored and should be 
omitted when the DDNAME parameter 
appears (see "Cataloged Procedures"). 


DDNAME Subparameter:. 
ddname 


names a DD statement that, if present, 
supplies the attributes of the data 
set. If it is not present, the state- 
ment is ignored. 


DSNAME Parameter 


allows the programmer to specify the 
name of the data set to be created or 


‘to refer to a previously created data 


set. Various types of names can be 
specified as follows (see "Using the 
DD Statement" for a discussion of the 
various names): 


ualified_names: For data 
sets to be retrieved from or 
stored in the system catalog. 


e Generation data_group names: For 


an entire generation data group, 
or any single generation thereof. 


e Simple names: For data sets that 
are not cataloged. 


e Reference names: For data sets 
whose names are given in the 
DSNAME parameter of another DD 
statement in the same job. 


e Temporary names: For temporary 
data sets that are to be named for 


the duration of one job only. 


If the DSNAME parameter is omitted, 
the operating system assigns a unique 
name to the data set. (This parameter 
should be supplied for all except tem- 
porary data sets.) 


DSNAME_Subparameters: 

dsname 
specifies the fully qualified name of 
a data set. This is the name under 
which the data set can be cataloged or 
otherwise identified on the volume. 


dsname(element) 
specifies a particular generation of a 
generation data group, a member of a 
partitioned data set, or an area of an 
indexed sequential data set. To in- 
dicate a generation of a generation 
data group, the element is a zero or a 
Signed integer. To indicate a member 
of a partitioned data set, the element 
is a name. To indicate an area of an 
indexed sequential data set, the ele- 
ment is PRIME, OVFLOW, or INDEX. 
Refer to the section “Using the DD 
Statement" for information about 
generation data groups and examples of 
partitioned data sets. 


*, ddname 
indicates that the DSNAME parameter 
(only) is to be copied from a preced- 
ing DD statement in the current job 
step. 


*.stepname. ddname 
indicates that the DSNAME parameter 
(only) is to be copied from the DD 
Statement, ddname, that occurred in a 
previous step, stepname, in the cur- 
rent job. If this form of the sub- 
parameter appears in a DD statement of 
a cataloged procedure, stepname refers 
to a previous step of the procedure, 
or, if no such step is found, toa 
previous step of the current job. 


*,stepname. procstep. ddname 
indicates that the DSNAME parameter 
(only) is to be copied from a DD 
statement in a cataloged procedure. 
The EXEC statement that called for 
execution of the procedure, as well as 
the step and DD statement of the pro- 
cedure, must be identified. 


éname 
allows the programmer to supply a tem- 
porary name for a data set that is to 
be deleted by the end of the job. The 
operating system substitutes a unique 
symbol for this subparameter. The 
programmer can use the temporary name 


in other steps to refer to the data 
set. The same symbol is substituted 
for each recurrence of this name 
within the job. Upon completion of 
the job, the name is dissociated from 
the data set. The same temporary name 
can be used in other jobs without 
ambiguity. 


&name (element) 
allows the programmer to supply a name 
for a member of a temporary parti- 
tioned data set that will be deleted 
at the end of the step. 


DCB Parameter 


allows the programmer to specify at 
execution time, rather than at the 
time of compilation, information for 
completing the data control block 
associated with the data set. For 
further information about the data 
control block and DCB subparameters 
see "Execution Time Data Set Require- 
ments" and “Additional File Processing 
Information." 


The first subparameter of this parame- 
ter may be used to copy DCB attributes 
from the data set label of a cataloged 
data set or from a preceding DD 
statement. 


SEP_and_ AFF Parameters 
allow the programmer to optimize the 
use of channels among groups of data 
sets. SEP indicates channel separa- 
tion and AFF indicates channel 


affinity. 


If neither parameter is supplied, any 
available channel, consistent with the 
UNIT parameter requirement, is 
assigned. The affinity parameter 
groups two or more data sets so that 
they can be separated from another 
data set requesting channel separa- 
tion. For indexed sequential data 
sets these parameters are written as 
for any data set. They can be used in 
succeeding DD statements to refer to 
the first DD statement defining an 
indexed sequential data set. However, 
the second and third DD statements 
cannot request separation from or 
affinity to one another because they 
are unnamed. Thus, to establish chan- 
nel separation and affinity for all of 
the areas, the name subparameter of 
the UNIT parameter must be used to 
request specific devices on specific 
channels. 


UNIT_Parameter 
specifies the quantity and types of 
input/output devices to be allocated 
for use by the data set. 
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If the UNIT parameter is not specified 
in the current DD statement, there are 
several ways in which the unit infor- 
mation may be inferred by the system: 


e If the current data set has 
already been created and it is 
either being passed to the current 
step, or if it has been cataloged, 
any unit name specified in this DD 
statement is ignored. 


e If the REF subparameter of the 
VOLUME parameter is specified, the 
current data set is given affinity 
with the data set referred to; 
that data set's defining DD state- 
ment provides the unit 
information. 


e If the current data set is to 
operate in the split cylinder mode 
with a previously defined data 
set, it will reside on the unit 
specified in the DD statement for 
the previous data set. 


e If the current data set is to use 
space suballocated from that 
assigned to a previously defined 
data set, it will reside on the 
same unit as the data set from 
which the space is obtained. 


e If the current data set is 
assigned to the standard output 
class (SYSOUT is specified), it is 
written on the unit specified by 
the operator for class A. 


If the current data set is in the input 
stream (defined by a DD * or DD DATA state- 
ment), the DD statement defining the data 
set should not contain a UNIT parameter. 


If this parameter specifies a direct- 
access device for a data set being created, 
it is also necessary to reserve the space 
the data set will occupy, using another 
parameter of the DD statement. Depending 
on the way in which the space will be used, 
the SPACE, SPLIT, or SUBALLOC parameter can 
be specified. These parameters are dis- 
cussed under individual headings. 


If the UNIT parameter specifies a tape 
device, no SPACE, SPLIT, or SUBALLOC par- 
ameters are required. 


The UNIT parameter must be specified if 


VOLUME=SER is specified in the DD 
statement. 
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UNIT Subparameters: 


name 
specifies the name of an input/output 
device, a single cell within a data 
cell drive, a device class name, or 
any meaningful combination of input/ 
output devices specified by an instal- 
lation. (Direct-access devices and 
IMagnetic tape devices can be combined. 
No other device type combination is 
allowed.) Names and device classes 
are defined at system generation time. 
The device class names that are 
required for IBM cataloged procedures 
and are normally used by most instal- 
lations are shown in Figure 6. These 
names can be specified by the instal- 
lation at system generation time. 


The block size specified in the source 
program (in the BLOCK CONTAINS clause or in 
the record description) must not exceed the 
Maximum block size permitted for the 
device. For example, the maximum block 
Size for the IBM 2311 is 3,625 characters, 
and the maximum block size for the IBM 2400 
series is 32,760 characters. 


Note: When device-independence is speci- 
fied by means of the ASSIGN TO...UTILITY 
statement in the Environment Division, the 
device chosen by the system will be depen- 
dent on the DD statement. Therefore, if 
the user's installation has both an IBM 
2311 and an IBM 2302 that may be used as 
utility devices, the user should write 
BLOCK CONTAINS 3625 CHARACTERS (or any 
number smaller than 3625) to ensure that 
the block can be contained on one track. 


}---------- 4--------------- fo------------- { 


}SYSSOQ jwriting jdirect-access | 
] | reading |magnetic tape | 
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Device Class Names Required for 
IBM-Supplied Cataloged 


Procedures 
n 
specifies the number of devices to be 
allocated to the data set. If this 
parameter is omitted, 1 is assumed. 
P 
specifies parallel mount. 
DEFER 


indicates deferred mounting. Deferred 
mounting cannot be specified for a new 
output data set on a direct-access 
device or for an indexed sequential 
data set. 


SEP=(list of ddnames) 
specifies unit separation. 


AFF=ddname 
specifies unit affinity. 


SPACE Parameter 
specifies space to be allocated ina 
direct-access volume. Although SPACE 
has no meaning for tape volumes, if a 
data set is assigned to a device class 
that contains both direct-access 
devices and tape devices, SPACE should 
be spécified. 


Two forms of the SPACE parameter 
may be used, with or without absolute 
track address. ABSTR requests that 
allocation begin at a specific 
address. 


SPACE Subparameters: 

ABSTR 

TRK 

CYL 

average-record-length 
specifies the unit of measurement in 
which storage is to be assigned. The 
units may be tracks (ABSTR,TRK), 
cylinders (CYL), or records (average- 
record-length expressed in decimal 
numbers). In addition, ABSTR indi- 
cates that the allocated space is to 
begin at a specific track address. If 
the specified tracks are already allo- 
cated to another data set, they will 
not be reallocated to this data set. 


Note: For indexed sequential data sets, 
only the CYL or ABSTR subparameter is per- 
mitted. Neither the TRK subparameter nor 
the average record length can be specified. 
When an indexed sequential data set is 
defined by more than one DD statement, all 
must specify either CYL or ABSTR; if some 
statements contain CYL and others ABSTR, 
the job will be abnormally terminated. 


(Primary-quantity[, secondary-quantity] 

{,directory or index quantity]) 
specifies the amount of space to be 
allocated for the data set. The pri- 
Mary quantity indicates the number of 
records, tracks, or cylinders to be 
allocated when the job step begins. 
For indexed sequential data sets, this 
subparameter specifies the number of 
cylinders for the prime, overflow, or 
index area (see "Execution Time Data 
Set Requirements"). The secondary 
quantity indicates how much additional 
space is to be allocated each time 
previously allocated space is 
exhausted. This subparameter must not 
be specified when defining an indexed 
sequential data set. The directory 
quantity is used when initially creat- 
ing a partitioned data set (PDS), and 


it specifies the number of 256-byte 
records to be reserved for the direc- 
tory of the PDS... It can also specify 
the number of cylinders to be allo- 
cated for an index area imbedded 
within the prime area when a new in- 
dexed sequential data set is being 
defined (see the section "Special 
Applications of the Control State- 
ments" in the publication IBM 
Job_Con- 


Note: The directory contains the name and 
the relative position, within the data set, 
for each member of a partitioned data set. 
The name requires 8 bytes, the location 4 
bytes. Up to 62 additional bytes can be 
used for additional information. For a 
directory of a partitioned data set that 
contains load modules, the minimum direc- 
tory requirement for each member is 34 
bytes. 


RLSE 
indicates that all unused external 
storage assigned to this data set is 
to be released when processing of the 
data set is completed. 


MXIG 
ALX 
CONTIG 


qualifies the request for the space to 
be allocated to the data set. MXIG 
requests the largest single block of 
storage that is greater than or equal 
to the space requested in the primary 
quantity. ALX requests the allocation 
of additional tracks in the volume. 
The operating system will allocate 
tracks in up to five blocks of 
storage, each block equal to or great- 
er than the primary quantity. CONTIG 
requests that the space indicated in 
the primary quantity be contiguous. 


If this subparameter is not speci- 
fied, or if any option cannot be ful- 
filled, the operating system attempts 
to assign contiguous space. If there 
is not enough contiguous space, up to 
five noncontiguous areas are 
allocated. 


ROUND : 
indicates that allocation of space for 
the specified number of records is to 
begin and end on a cylinder boundary. 
It can be used only when average rec- 
ord length is specified as the first 
subparameter. 
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quantity 


specifies the number of tracks to be 
allocated. For an indexed sequential 
data set, this quantity must be equi- 
valent to an integral number of cylin- 
ders; it specifies the space for the 
prime, overflow, or index area (see 
"Execution Time Data Set Require- 
ments"), 


beginning address 


specifies the relative number of the 
track desired, where the first track 
of a volume is defined as 0. (Track 0 
cannot be requested.) The number is 
automatically converted to an address 
based on the particular device 
assigned. For an indexed sequential 
data set this number must indicate the 
beginning of a cylinder. 


directory quantity 


defines the number of 256-byte records 
to be allocated for the directory of a 
new partitioned data set. It also 
specifies the number of tracks to be 
allocated for an index area embedded 
within the prime area when a new in- 
dexed sequential data set is being 
defined. In the latter case, the 
number of tracks must be equivalent to 
an integral number of cylinders (see 
the section "Special Applications of 
the Control Statements" in the publi- 
cation IBM System/360 Operating Sys- 
tem: Job Control _ Language, Form 


C28-6539). 


SPLIT Parameter 


Note: 


is specified when other data sets in 
the job step require space in the same 
direct-access volume, and the user 
wishes to minimize access-arm movement 
by sharing cylinders with the other 
data sets. The device is then said to 
be operating in a split cylinder mode. 
In this mode, two or more data sets 
are stored so that portions of each 
occupy tracks within every allocated 
cylinder. 


SPLIT should not be used when one of 


the data sets is an indexed sequential data 


set. 


SPLIT _Subparameters: 


n 
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indicates the number of tracks per 
cylinder to be used for this data set 
if CYL is specified. If the average 
record length is specified, n is the 
percentage of the tracks per cylinder 
to be used for this data set. 


{oe \ 

average-record-length 
indicates the units in which the space 
requirements are expressed in the next 
subparameter, The units may be cylin- 
ders (CYL) or physical records (in 
which case the average record length 
in bytes is specified as a decimal 
number not exceeding 65,535). If the 
average record length is given, and 
the data set is defined to have a key, 
the key length must be given in the 
DCB parameter of this DD statement. 


primary-quantity 
defines the number of cylinders or 
space for records to be allocated to 
the entire group of data sets. 


secondary-quantity 
defines the number of cylinders or 
Space for records to be allocated each 
time the space allocated to any of the 
data sets in the group has been 
exhausted and more data is to be writ- 
ten. This quantity will not be split. 


A group of data sets that share cylin- 
ders in the same device is defined by a 
sequence of DD statements. The first 
statement in the sequence must specify all 
parameters except secondary quantity, which 


‘is optional. Each of the statements that 


follow must specify only n, the amount of 
space required. 


SUBALLOC_ Parameter 
permits space to be obtained from 
another data set for which contiguous 
space was previously allocated. This 
enables data sets to be stored in a 
Single volume. Space obtained through 
suballocation is removed from the 
Original data set, and may not be 
further suballocated. The SUBALLOC 
parameter should not be used to obtain 
space for an indexed sequential data 
set. 


Except for the subparameters 
described below the subparameters in 
the SUBALLOC parameter have the same 
meaning as those described in the 
SPACE parameter. 
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ddname 
indicates that space is to be suballo- 
cated from the data set defined by the 
DD statement, ddname, that appears in 
the current step. 


stepname. ddname 
indicates that space is to be suballo- 
cated from the data set defined by the 
DD statement, ddname, occurring in a 
previous step, stepname. If this form 
of the subparameter appears in a DD 
statement in a cataloged procedure, 
stepname refers to a previous step of 
the procedure, or if no such step is 
found, to a previous step of the cur- 
rent job. 


stepname. procstep. ddname 
indicates that space is to be suballo- 
cated from a data set defined ina 
cataloged procedure. The first term 
identifies the step that called for 
execution of the procedure, the second 
identifies the procedure step, and the 
third identifies the DD statement 
which requested space originally. 


VOLUME Parameter 
specifies information about the 
volume(s) on which an input data set 
resides, or on which an output data 
set will reside. A volume can be a 
tape reel, a disk pack, part of a disk 
storage drive, or a data cell. 

Volumes can be used most efficiently 
if the programmer is familiar with the 
states a volume can assume. Volume 
States involve two criteria: the type 
of data set the programmer is defining 
and the manner in which the programmer 
requests a volume. 


Data sets can be classified as one of two 
types, temporary or nontemporary. A tem- 
porary data set exists only for the dura- 
tion of the job that creates it. A nontem- 
porary data set can exist after the job is 
completed. The programmer indicates that a 
data set is temporary by coding: 


e DSNAME=é&name 


¢ No DSNAME parameter 


¢ DISP=(NEW, DELETE), either explicitly or 
implied, e.g., DISP=(,DELETE) 


e DSNAME=reference, referring to a DD 
statement that defines a temporary data 
set. 


All other data sets are considered nontem- 
porary. If the programmer attempts to keep 
or catalog a passed data set that was 
declared temporary, the system changes the 
disposition to PASS unless. DEFER was speci- 
fied in the UNIT parameter. Such a data 
set is deleted at the end of the job. 


The manner in which the programmer requests 

ecific A specific reference is implied 
whenever a volume with a specific serial 
number is requested. Any one of the fol- 
lowing conditions denotes a specific volume 
reference: 


e The data set is cataloged or passed 
from an earlier job step. 


e VOLUME=SER is coded in the DD 
statement. 


e VOLUME=REF is coded in the DD state- 
ment, referring to an earlier specific 
volume reference. 


All other types of volume references are 
nonspecific. (Nonspecific references can 
be made only for new data sets, in which 
case the system assigns a suitable volune. ) 


The state of a volume determines when 
the volume will be demounted and what kinds 
of data sets can be assigned to it. 
Direct-Access_Volumes: Direct-access 
volumes differ from tape volumes in that 
they can be shared by two or more data sets 
processed concurrently by more than one 
job. Because of this difference, direct- 
access volumes can assume different volume 
states than tape volumes. The volume state 
is determined by one characteristic from 
each of the following groups: 


Mount Allocation 
Characteristics Characteristics 
Permanently Resident Public 

Reserved Private 
Removable Storage 


Permanently resident volumes are always 
mounted. The permanently resident charac- 


teristic applies automatically to: 


e All physically nondemountable volumes, 
such as 2301 Drum Storage. 


e The volume from which the system is 
loaded (the IPL volume). 


e The volume containing the system data 
sets SYS1.LINKLIB, SYS1.PROCLIB, and 
SYS1.SYSJOBQE. 


e Other volumes can be designated as per- 
manently resident in a special member 
of SYS1.PROCLIB named PRESRES. 


Permanently resident volumes are always 
public. The reserved characteristic ap- 
plies to volumes that remain mounted until 
the operator issues an UNLOAD command. 

They are reserved by a MOUNT command refer- 
ring to the unit on which they are mounted 
or by a PRESRES entry. The removable 
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characteristic applies to all volumes that 
are neither permanently résident nor 
reserved. Removable volumes do not have an 
allocation characteristic when they are not 
mounted. A reserved volume becomes remov- 
able after an UNLOAD command is issued for 
the unit on which it resides. 


The allocation characteristics, public, 
private, and storage, deal with a volume's 
availability to be assigned by the system 
to temporary data sets, and, if the volume 
is removable, when it is to be demounted. 


A public volume is used primarily for 
temporary data sets and, if it is per- 
manently resident, for frequently used data 
sets. It must be requested by a specific 
volume reference if a data set is to be 
kept or cataloged on it. If a public 
volume is removable, it is demounted only 
when its unit is required by another 
volume. The programmer can change a 
removable/public volume to private by spec- 
ifying VOLUME=PRIVATE. 


A private volume must be requested by a 
specific volume reference. A new data set 
can be assigned to a private volume by 
specifying VOLUME=PRIVATE. If the volume 
is reserved, it remains mounted until the 
operator issues an UNLOAD command for the 
unit on which it resides. If it is remov- 
able, it will be demounted after it is used 
unless the programmer specifically 
requested that it be retained (VOLUME= 
RETAIN) or passed (DISP=PASS). Once a re- 
movable volume has been made private, it 
will ultimately be demounted. To use it as 
a public volume, it must be remounted. 


A storage volume is used as an extension 
of main storage, to keep or catalog nontem- 
porary data sets having non-specific volume 
requests. The programmer can assign the 
PRIVATE option to storage volumes. 


Table 2 shows how direct-access volumes 
are assigned their mount and allocation 
characteristics. 


Table 2. Direct-Access Volume States 


eee Be ret pe ey ee 1 
| glenn Characteristic | 


l Mount = }--------7--------7-------- 
{Characteristic] Public {Private | Storage ] 
|-------------- }-------- }-------- }-------- { 
{Permanently |PRESRES |PRESRES |PRESRES | 
| Resident | or | | | 
| |DEFAULT | | | 
| Reserved | PRESRES |PRESRES |PRESRES | 
| Jor MOUNT|or MOUNT|or MOUNT] 
| [command [command |command | 
~------------- }--------}--------}--------4 
}Removable {Default |VOLUME= | N/A | 
| | | PRIVATE | | 
les eo sooo ss Ds ee cet eS a J 
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Magnetic Tape Volumes: The volume state of 
a reel of Segherie ee tape is also determined 
by a combination of mount and allocation 
characteristics: 


Mount Allocation 
Characteristics Characteristics 
Reserved Private 
Removable Scratch 


The reserved/scratch combination is not a 
valid volume state. Reserved tape volumes _ 
assume their state when the operator issues 
a MOUNT command for the unit on which they 
reside. They remain mounted until the 
operator issues a corresponding UNLOAD com- 
mand. Reserved tapes must be requested by 
a specific volume reference. 


lowing occurs: 


e It is requested with a specific volume 
reference. 


e It is requested for allocation to a 
nontemporary data set. 


e The VOLUME parameter is coded with the 
PRIVATE option. 


A removable/private volume is demounted 
after its last use in the job step, unless 
the programmer requests that it be 
retained. 


All other tape volumes are assigned the 
removable/scratch state. They remain 
mounted until their unit is required by 
another volume. 


Volume Parameter Facilities: The facil- 
ities of the VOLUME parameter allow the 
programmer to: 


e Request private volumes (PRIVATE) 


e Request that private volumes remain 
mounted until the end of the job 
(RETAIN) 


e Select particular volumes when the data 
set resides on more than one volume 
(seq#) 


e Request more than one nonspecific 
volume (volcount) 

e Identify specific volumes (SER and REF) 
These facilities are all optional. The 
programmer can omit the VOLUME parameter 
when defining a new data set, in which case 
the system assigns a suitable public or 
scratch volume. 


VOLUME Subparameters: 


PRIVATE 
indicates that the volume on which 
space is being allocated to the data 
set is to be made private. If the 
PRIVATE, SER, and REF subparameters 
are omitted for a new output data set, 
the system assigns the data set to any 
suitable public or scratch volume that 
is available. 


RETAIN 
indicates that this volume is to 
remain mounted after the job step is 
completed. Volumes are retained so 
that data may be transmitted to or 
from the data set, or so that other 
data sets may reside in the volume. 
If the data set requires more than one 
volume, only the last volume is 
retained; the other volumes will have 
been demounted previously. Another 
job step indicates when to demount the 
volume by omitting RETAIN. If each 
job step issues a RETAIN for the 
volume, the retained status lapses 
when execution of the job is 
completed. 


volume-sequence-~number 
is a 1- to 4-digit number that speci- 
fies the sequence number of the first 
volume of the data set that is read or 
written. The volume sequence number 
is meaningful only if the data set is 
cataloged and earlier volumes are 
omitted. 


volume-count 
specifies the number of volumes 
required by the data set. Unless the 
SER or REF subparameter is used, this 
subparameter is required for every 
multi-volume output data set. 


SER 
specifies one or more serial numbers 
for the volumes required by the data 
sets. A volume serial number consists 
of one to six alphanumeric characters. 
If it contains fewer than six charac- 
ters, the serial number is left 
adjusted and padded with blanks. If 
SER is not specified, and DISP is not 
specified as NEW, the data set is 
assumed to be cataloged, and serial 
numbers are retrieved from the cata- 
log. A volume serial number is not 
required for new output data sets. 
Two volumes should not have the same 
serial number. When the SER parameter 
is included, the volume is treated as 
PRIVATE commencing with allocation for 
the current job step. 


If this subparameter is specified, the 
UNIT parameter must also be specified. 


REF 
indicates that the data set is to 
occupy the same volume(s) as the data 
set identified by dsname *.ddname, 
*,stepname.ddname, or *.stepname. 
procstep.ddname. Table 3 shows the 
data set references. 


When the data set resides in a tape 
volume and REF is specified, the data set 
is placed in the same volume, immediately 
behind the data set referred to by this 
subparameter. When the REF subparameter is 
used, the UNIT and LABEL parameters, if 
supplied, are ignored. 


If SER or REF is not specified, the con- 
trol program will allocate any nonprivate 
volume that is available. 


Data Set References 


name | 


Se Sm ce a ca a ce ce ce eee ee tee cee ee ee ae ce ee ee ee ee ee re ee ee ee ee ae ae ee 


~-------------- }-------------------------4 
|REF=dsname ja data set named dsname_ | 
Sn ee eee ea 4—~---__----------------- 
| REF=*,. ddname Ja data set indicated by | 
] { DD statement ddname in | 
| {| the current job step | 
Se ae a ae 4-----------~-----------~- 
J REF=*.stepname.|a data set indicated by| 
ddname | DD statement ddname | 
} ain the job step step-| 

| 

+ 


]REF=*.stepname.Ja data set indicated by| 
procstep.| DD statement ddname | 
ddname |] in the cataloged pro-| 
| cedure step procstep| 
{| called in the job step| 
| stepname. (See the | 
J chapter, "Cataloged | 
| Procedures. ") | 
41 


uu 


LABEL Parameter 


specifies information about the label 
or labels associated with the data 
set. If a data set is passed from a 
previous job step, label information 
is retained from the DD statement that 
specified DISP=(,PASS). A LABEL par- 
ameter, if specified in the DD state- 
ment receiving the passed data set, is 
ignored. If the LABEL parameter is 
omitted and the data set is not being 
passed, standard labeling is assumed. 
The operating system verifies mounting 
when the label parameter specifies SL. 
Nonstandard labels can be specified 
only when installation-written rou- 
tines to write and process nonstandard 
labels have been incorporated into the 
Operating system. Refer to the publi- 
cation IBM System/360 Operating Sys- 
tem: ___System_ Programmer's Guide, Form 
C28-6550, for a description of how to 
write such routines. No label infor- 
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mation is required for direct-access 
devices. 


LABEL Subparameters: 


data-set-~sequence-number 


\ 


“The period of 


is a 4-digit number that identifies 
the relative location of the data set 
with respect to the first data set in 
a tape volume. (For example, if there 
are three data sets in a magnetic tape 
volume, the third data set is identi- 
fied by data set sequence number 
0003.) If the data set sequence 
number is not specified, the operating 
system assumes 0001. (This option 
should not be confused with the volume 
sequence number, which represents a 


' particular volume for a data set.) 


specifies the kind of label used for 
the data set. NL indicates no labels. 
SL indicates standard labels. NSL 
indicates nonstandard labels. 


cette ac 
RETPD=xXxxx 


specifies how long the data set shall 
exist. The expiration date, EXPDT= 
yyddd, indicates the year (yy) and the 
day (ddd) the data set can be deleted. 
retention, RETPD=xxxx, 
indicates the period of time, in days, 
that the data set is to be retained. 
If neither is specified, the retention 
period is assumed to be zero. 


DISP_ Parameter 
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describes the status of a data set and 
indicates what is to be done with it 
after its last use, or at the end of 
the job. The job scheduler executes 
the requested disposition functions at 
the completion of the associated job 
step. If the step is not executed 
because of an error found by the sys- 
tem before trying to initiate the step 
(e.ge, an error in a job control lan- 
guage statement), the remaining state- 
ments are read and interpreted; howev- 
er, none of the succeeding steps are 
executed, and the requested disposi- 
tions are not performed. This param- 
eter can be omitted for data sets 
created and deleted during a single 
job step. Additional information 
about the relationship between the 
DISP parameter and the volume table of 
contents is contained in the chapter, 
"Additional File Processing Infor- 
mation." 


DISP_ Subparameters: 


NEW 


OLD 


SHR 


MOD 


indicates that the data set is Leing 
generated in this step. If the status 
is omitted, NEW is assumed. 


indicates that the data set specified 
in the DSNAME parameter already 
exists. 


has meaning only in a multiprogramming 
environment for existing data sets 
that reside on direct-access volumes. 
This subparameter indicates that the 
data set is part of a job in which 
operations do not prevent simultaneous 
use of the data set by another job. 
For a data set that is to be shared, 
the DD statement DISP parameter should 
be specified as DISP=SHR for every 
reference to the data set in a job. 
Unless this is done, the data set can- 
not be used by a concurrently operat- 
ing job, and the job will have to wait 
until the particular file is free. 
DISP=SHR can also be specified under 
PCP (the primary control program) in 
which the system will assume an OLD 
disposition. 


causes logical positioning after the 
last record in the data set. It indi- 
cates that the data set already exists 
and that it is to be added to, rather 
than read. If MOD is specified and 
(1) the volume serial number is not 
given, and (2) the data set is not 
cataloged or passed from an earlier 
job step, MOD is ignored and NEW is 
assumed. If the volume serial number 
is given, the data set is assumed to 
reside on the specified volume. 


DELETE 


KEEP 


causes the space occupied by the data 
set to be released for other purposes 
at the end of the current step. If 
the data set is cataloged, and the 
catalog is used to locate it, 
reference to the data set is removed 
from the catalog. If it is ona 
direct-access device, all references 
are removed from the volume table of 
contents, and the device space is made 
available for use by other data sets. 
If the data set is on tape, the volume 
in which the data set resides is then 
available for use by other data sets. 


ensures that the data set remains 
intact until a DELETE parameter is 
exercised in either the current job or 
some subsequent job. If the data set 


PASS 


CATLG 


is on a direct-access device, it 
remains tabulated in the volume table 
of contents after completion of the 
job. When the volume containing the 
data set is to be demounted, the 
operator is advised of the 
disposition. 


indicates that the data set is to be 
referred to in a later step of the 
current job, at which time its dis- 
position may be determined. When a 
subsequent reference to this data set 
is encountered, its PASS status lapses 
unless another PASS is issued. The 
final disposition of the data set 
should be specified in the last DD 
statement referring to the data set 
within the current job. 


While a data set is in PASS status, 
the volume or volumes in which it 
resides are, in effect, retained; that 
is, the system will attempt to avoid 
demounting them. If demounting is 
necessary, the system will ensure 
proper remounting, through operator 
messages. The unit name specified on 
the DD statement in the receiving step 
must be consistent with the unit name 
in the passing step. 


causes the creation, at the end of the 
job step, of an index entry in the 
system catalog pointing to the data 
set. The data set can be referred to 
by name in subsequent jobs, without 
the need for volume serial number or 
device type information from the pro- 


causes the index entry that points to 
this data set to be removed from the 
index structure at the end of this 
step. The data set is not deleted. 
If it is on a direct-access volume, 
reference to it remains in the volume 
table of contents. 


SYSOUT Subparameters: 


classname 


Note: 
used 


are not sufficient. 


specifies the system output class on 
which the data set is to be written. 

A classname is an installation- 
specified 1-character name designating 
the output class to which the data set 
is to be written. Each classname is 
related to a particular output unit. 
Valid values for this parameter are A 
through Z and 0 through 9. A is the 
standard output class. Both data sets 
and system messages can be routed 
through the same output stream when 
using a priority scheduler. In this 
case, the output class selected for 
the data sets must be the same output 
class as that selected for the 
MSGCLASS parameter in the JOB state- 
ment. SYSOUT=B should be specified 
for any data set that is to be 
punched, under PCP, MFT, or MVT. The 
priority scheduler will route the out- 
put to class B. In an MVT environ- 
ment, this will allow jobs to execute 
concurrently with the punching of out- 
put data. 


Classes 0 through 9 should not be 
except in cases when the other classes 
These classes are 


intended for future features of systems 
using priority schedulers. 


(x{, program-name] [, form-no. ]) 


is used for priority scheduling sys- 
tems only. When priority schedulers 
are used, the data set is written on 


grammer. Cataloging also implies an intermediate direct-access device 
KEEP. during program execution, and later 
routed through an output stream to a 

UNCATLG system output device. The letter x 


can be an alphabetic or numeric 
character specifying the system output 
class. Output writers route data from 
the output classes to system output 
devices. The DD statement for this 
data set can also include a unit spec- 
ification describing the intermediate 
direct-access device and an estimate 
of the space required. If there is a 


special installation program to handle 
output operations, its program-name 
should be specified. Program-name is 
the member name of the program, which 
must reside in the system library. If 
the output data set is to be printed 
Or punched on a specific type of out- 
put form, a 4-digit form-no. should 
be specified. This form number is 
used to instruct the operator of the 
form to be used in a message issued at 
the time the data set is to be 
printed. 


Note: The absence of DELETE, KEEP, PASS, 
CATLG, and UNCATLG indicates that no spe- 
cial action is to be taken to alter the 
permanent or temporary status of this data 
set. If the data set was created in this 
job, it will be deleted at the end of the 
current step. If the data set existed 
before this job, it will be kept. 


SYSOUT_Parameter 
schedules a printing or punching 
Operation for the data set described 


by the DD statement. 
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Note: If the program-name: and form-no. 
are omitted, the delimiting parentheses can 
be omitted. 


JOBLIB DD STATEMENT 


The JOBLIB statement is a unique DD 
statement. It is used when one or more 
load modules to be executed in the job are 
members of a private library. When used, 
the JOBLIB statement must be placed after 
the JOB statement and before the first EXEC 
statement in the input stream. The ddname 
JOBLIB is specified in the name field of 
the statement. 


If a job step other than the first is 
the one to execute the load module from the 
private library, the JOBLIB statement must 
specify the DISP parameter with PASS as the 
second subparameter. Only one JOBLIB 
statement can be specified for a ‘job, but 
other libraries can be concatenated with 
the library named in the JOBLIB statement. 


The JOBLIB statement concatenates the 
named library with the system library. It 
does not have to be specified for load 
modules created in the job, or for per- 
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manent members of the system library. (See 
"The Checklist for Job Control Procedures" 
for examples. ) 


The delimiter statement (Figure 7) is 
used to separate data from subsequent con- 
trol statements in the input stream, and is 
placed after each data set in the input 
stream. It is required only when job con- 
trol statements and data appear together. 


The delimiter statement is not required 
to mark the end of a data set defined with 
a DD * statement when using a system with 
MFT or MVT. 


The delimiter statement contains a slash 
in column 1, an asterisk in column 2, and a 
blank in column 3. The remainder of the 
card may contain comments. 


Far OR ee oe eee a eS ee 1 
| Name | Operation] Operand | 
Pela Seeded Se gO (On hy icles pens en Pte a ae a | 
|7* | | | 
Gececteosee eee 5 pe ee nO mae me vA ee Re J 


Figure 7. Delimiter Statement 


Nine data sets may be defined for a com- 
pilation job step; six of these (SYSUT1, 
SYSUT2, SYSUT3, SYSUT4, SYSIN, and SYS- 
PRINT) are required. The other three data 
sets (SYSLIN, SYSPUNCH, and SYSLIB) are 
optional. 


For compiler data sets other than utili- 
ty data sets, a logical record size can be 
specified by using the LRECL and BLKSIZE 
subparameters of the DCB parameter. The 
values specified must be permissible for 
the device on which the data set resides. 
LRECL equals the logical record size, and 
BLKSIZE equals (n*LRECL) where n is equal 
to the blocking factor. If this informa- 
tion is not specified on the DD statement, 
it is assumed that the logical record sizes 
for the unblocked data sets have the fol- 
lowing default values: 

SYSIN, SYSLIN, SYSPUNCH, SYSLIB: 
80 bytes each 
SYSPRINT: 121 bytes 


(See Appendix D for information about allo- 
cation of buffer space for these data 
sets.) The ddname that must be used in the 
DD statement describing the data set 
appears as the heading for each description 
that follows. Table 4 lists the function, 
device requirements, and allowable device 
classes for each data set. (See Appendix D 
for further information on blocked compiler 
data sets other than utility data sets.) 


SYSUT1, SYSUT2, SYSUT3, SYSUT4 


The DD statements using these ddnames 
define utility data sets that are used by 
the compiler when processing the source 
module. The data set defined by the SYSUT1 
DD statement must be on a direct-access 
device. These data sets are temporary and 
have no connection with any other job step. 
For example, the DD statement 


//SYSUT1 DD UNIT=SYSDA, SPACE=(TRK, (40,10) ) 


specifies that the data set is to be writ- 
ten on any available direct-access device, 
with a primary allocation of 40 tracks. 
Additional tracks, if required, are to be 
allocated in groups of 10. The data set is 
to be deleted at the end of the job step 
(by default). 


Note: When compiling large programs, if 
the primary space allocated for the data 
set is insufficient, an area of core 
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storage may be used to complete processing. 
Then, when additional core storage is 
needed during compilation, enough contig- 
uous space may not be available to load a 
compiler phase. Such a condition will 
result in an abnormal termination of the 
job. The programmer should attempt to 
allocate enough primary space to eliminate 
the need for a secondary allocation. 


SYSIN 


The data set defined by the SYSIN DD 
statement contains the input for the com- 
piler, i-e., the source module statements 
that are to be processed. The input/output 
device assigned to this data set can be 
either the device transmitting the input 
stream (the device designated as SYSIN at 
system generation time) or a device desig- 
nated by the programmer. When using a 
cataloged procedure, the DD statement 
describing this data set usually appears in 
the input stream. For example, 


7/SYSIN DD * 


specifies that the input data set follows 
in the input stream. If the asterisk or 
DATA convention is used, the SYSIN DD 
statement must be the last DD statement in 
the job step. 


SYSPRINT 


This data set is used by the compiler to 
produce a listing. Output may be directed 
either to a printer, to a direct-access 
device, or to a magnetic-tape device. The 
listing will include the results of either 
the default or the specified options of the 
PARM parameter (i.e., diagnostic messages, 
the object code listing). For example, in 
the DD statement 


7/SYSPRINT DD SYSOUT=A 


SYSOUT is the disposition for printer data 
sets, and A is the standard output class 


‘for printer data sets. 


Note: If SYSOUT=A is not specified for 
SYSPRINT, MOD must be specified in the DISP 
parameter. 


Compiler Data Set Requirements 41 


Table 4, Data Sets Used for Compilation 
Sealand aa aeg oS te a aaa a Posts De ee eg | 
| | | | {| Allowable | 
| ddname | Type { Function {Device Requirements |Device Classes | 
[-----—--- t----------—- $--------------------- ~~---}-------------------- 4--------------+---------- { 
| SYSIN -| INPUT/OUTPUT | Reading. the source programjcard reader |SYSSQ or the input stream| 
| (required) | ] Jintermediate storage| device (specified by DD] 
| | | | | * or DD DATA) 
}---------- }--------------------------}--------------------4------------------------- 
{|SYSPRINT | |Writing the storage map, [printer |SYSSQ, SYSDA, standard | 
| (required) | | listings, and messages |jintermediate storage| output class A | 
|SYSPUNCH | {Punching the object module]card punch 'SYSCP, SYSSQ, SYSDA, | 
| (optional) | |} deck ]direct-access | output class B | 
| | | {magnetic tape | | 
---------- { ~----~-----~--=-----------}-==----------------- f= -- === ---------------4 
| SYSLIN | |Creating an object module |direct-access |SYSSQ, SYSDA l 
| (optional) | | data set as output from |magnetic tape | | 
| t | the compiler and input | | 
| | { to the linkage editor { | { 
}---------- ¢----------— 4~------------------------- {-------------------- fanaa -2 nnn n nn { 
| SYSUT1 | UTILITY |Work data set needed by }direct-access | SYSDA | 
| (required) | { the compiler during 1 | t 
| | { compilation H | | 
b------——---{ sf --~-=-------------------- 4-------------------- 4------------------------- { 
|} SYSUT2 q {Work data set needed by jdirect-access |SYSSQ, SYSDA | 
| (cequired) | | the compiler during jmagnetic tape | | 
| | | compilation 1 | | 
-----—--- { ~----=----~---------------}--------------------}--------=---------------- 
| SYSUT3 | |Work data set needed by |]direct-access |SYSSQ, SYSDA | 
| (required) | | the compiler during ]magnetic tape | | 
| | | compilation | ‘| 
}-----—----{ }-------------------------- 4-------------------- 4------------------------- { 
| SYSUT4 1 {Work data set needed by |direct-access [SYSSQ, SYSDA t 
| (cequired) ] { the compiler during Jmagnetic tape | 
| {| compilation | | 
~--------- }----------—-}--------------------------}-------------------- f= == ------ === === 
| SYSLIB | LIBRARY |Optional user source ]direct-access | SYSDA | 
| (optional) | | program library i] | | 
Va a a a (AE ee ee ee es es 5 ieee eo ese eam raneee See eae J 
SYSPUNCH 4/SYSLIN DD DSNAME=&GOFILE, X 
4/ DISP=(MOD, PASS), X 
1/ UNIT=SYSDA, X 

The device defined by the SYSPUNCH DD 4/ SPACE=(TRK, (30,10)) 


statement is used to punch an object module 
deck. This data set can be directed to a 
card punch, direct-access device, or mag- 
netic tape. For example, in the DD 
statement 


//SYSPUNCH DD SYSOUT=B, UNIT=SYSCP 


SYSCP is the device class name for data 
sets that are to be punched. 


Note: If SYSPUNCH is defined as a parti- 
tioned data set (PDS), then it must pre- 
viously have been defined, and DISP=OLD 
must be specified. 


SYSLIN 


The device defined by the SYSLIN DD 
statement is used by the compiler to store 
an object module. It may be on a direct- 
access Or magnetic-tape device. For 
example: 
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The temporary name of the data set is 
GOFILE; the parameter DISP=(MOD, PASS) indi-~ 
cates that the data is to be created or 
added to in this job step and is to be 
passed to another job step, which may be 
the linkage editor step. The device to be 
assigned for storage is a direct-access 
device on which 30 tracks are initially 
allocated to the data set. If more space is 
n eeded, tracks are allocated 10 at a time. 


Note: If SYSLIN is defined as a parti- 

tioned data set (PDS), then it must pre- 
viously have been defined, and DISP=OLD 

must be specified. 


SYSLIB 


The SYSLIB DD statement defines the 
library (PDS) that contains the data 
requested by an INCLUDE or COPY statement 
(in the source module) or by a BASIS card 
in the input stream. Note that more than 


one partitioned data set may be used for 
the library function by concatenating them 
with SYSLIB (see the chapter entitled 
"Libraries" for an example). Libraries 
must always be on direct-access devices. 
Only one SYSLIB statement may be used ina 
compilation job step. For example, in the 
DD statement 


4/SYSLIB DD DSNAME=USERLIB, DISP=OLD 


the name of the library is USERLIB, and 
DISP=OLD indicates that the library has 
been created in a previous job. No other 
information need be given if the specified 
library has been cataloged. 
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Four data sets are required for linkage 
editor processing. Others may be necessary 
if secondary input is specified. In the 
following discussions the ddname that must 
be used in the DD statement describing the 
data set appears as the heading for each 
description of the particular data set. 
For any user-defined data set, the ddname 
is defined by the programmer. Table 5 
lists the function, device requirements, 
and allowable device classes for each data 
set. 


SYSLIN 


The SYSLIN DD statement defines the data 
set that is primary input to linkage editor 
processing. Normally this data set con- 
Sists of the output from a previous compi- 
lation job step. The primary input may 
also be linkage editor control statements, 
such as the INCLUDE, LIBRARY, or OVERLAY 
statements, but not job control statements 
(see "Calling and Called Programs"). The 
input device assigned to this data set is 
either the device transmitting the input 
stream, if the input is an object module 
deck, or a device designated by the pro- 
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grammer. However, the data set may simply 
be passed from the previous compilation job 


step. For example, in the DD statement 
//SYSLIN DD DSNAME=*. STEPNAME,. SYSLIN, x 
J/ DISP= (OLD, DELETE) 


the data set is defined in the SYSLIN DD 
statement contained in the compiler job 
step, STEPNAME. DISP=(OLD,DELETE) indi- 
cates that the data set was created in a 
previous job step and is to be deleted at 
the end of this job step. 


SYSPRINT 


The data set defined by the SYSPRINT DD 
statement is used by the linkage editor to 
produce a listing. Output may be directed 
to a printer or to magnetic tape. The 
listing may include any options specified 
by the PARM parameter of the EXEC statement 
(a module map or cross reference list, di- 
agnostic or informative messages, etc.). 
For example: 


//SYSPRINT DD SYSOUT=A 


Table 5. Data Sets Used For Linkage Editing 
ei lara a t= SSS Cees oe eee eS oe oa Se Reet oe er SO ee 1 
| | |Device | Allowable | 
| ddname | Type | Function |Requirements |Device Classes | 
ala eC aN TNE tS eee Se ee ee ee ee eee eee ee 
feta | INPUT/ eas input data, jdirect-access Mere, SYSDA, or the input | 
| (required) JOUTPUT ] normally the output | magnetic | stream device (specified| 
| ] ] of the compiler } tape card |} by DD * or DD DATA) | 
| | | | reader | | 
| | }--------------------- }-------------- 4-------------------------- { 
|SYSPRINT | {Diagnostic messages |printer |SYSSQ, standard output | 
| (required) | | informative messages| intermediate] class A | 
] | | module map } storage | | 
| | | cross reference list] device | | 
| J 00 fee--==--------------- 4-------------- 4-----+--------------------- { 
| SYSLMOD | ]Output data set for jdirect-access |SYSDA | 
| (required) / | the load module | | | 
-------------- 4-------}-----------------~----4--------------4--------------------------4 
| SYSUT1 JUTILITY|work data set {direct-access |SYSDA | 
| (required) | | | | | 
na----------- fonnnn anton nnn nn nnn nnn nnn penn nnn nnn nnn nnn nnn nnn nn nnn 
] SYSLIB | LIBRARY]Automatic call library|direct-access |SYSDA | 
{required for | | (sysi.COBLIB is the | | | 
]COBOL library | { name of the COBOL | | | 
| subroutines | | subroutine library) | | | 
[-------------- }------- 4--------------------- 4-------------- 4-------------------------- { 
| user-specified] {Additional object |direct-access |SYSDA, SYSSQ | 
| (optional) | | modules and load ] magnetic | | 
| ] | modules } tape | | 
beeen Soot ee i Ee eee flee pe a ee eee ee Begin eer es a Ae eres ee J 
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SYSLMOD 


The SYSLMOD DD statement defines the 
output data set, in this case the load 
module. The load module must be placed in 
a library as a named member. The library 
can be the Link Library (SYS1.LINKLIB) or a 
private user-defined library. Such 
libraries must always reside on a direct- 
access device, and space for the library is 
allocated when the library is created. For 
example, in the DD statement 


/4/SYSLMOD DD DSNAME=SYS1. LINKLIB (MEMBER), X 
// DISP=MOD 


the load module, MEMBER, is stored as a 
member of the link library. DISP=MOD indi- 
cates that the library is already created 
and is to be added to. 


//SYSLMOD DD DSNAME=LIB1 (BALANCE), Xx 
1/7 DISP=(NEW, CATLG), Xx 
7/ VOLUME=SER=11111, X 
// SPACE=(TRK, (40,10,1)), x 
Jf UNIT=SYSDA 

The load module, BALANCE, is to be a member 
of a library, LIB1, which is to be created 


in this job step, with BALANCE as its first 
member. The direct-access volume to which 
it is directed is identified by the serial 
number, 11111. A primary quantity of 40 
tracks is allocated to the library with an 
additional allocation for one 256-byte 
record to be used for the directory. 
more space is needed for the library, 
tracks are added, 10 at a time. (However, 
no additional space can be allocated for 
the directory.) 


If 


Note: If the load module is placed ina 

private library, the JOBLIB DD statement 

must be specified in subsequent jobs that 
execute load modules from the library. 
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SYSUT1 


The SYSUT1 DD statement defines a utili- 
ty data set used by the linkage editor when 
processing object modules and load modules. 
The data set must be on a direct-access 
device. It is a temporary data set and has 
no connection with any other job step. For 
example: 


//SYSUT1 DD UNIT=SYSDA, SPACE=(TRK, (40, 10)) 


The data set is initially allocated 40 
tracks on any available direct-access 
device. If more space is needed, tracks 
are added, 10 at a time. A temporary name 
is assigned to the data set for the job 
step. 


SYSLIB 


The SYSLIB DD statement assigns the 
named partitioned data set to the automatic 
call library from which modules may be 
automatically obtained by the linkage edi- 
tor to resolve external references. 


/7/SYSLIB DD DSNAME=SYS1.COBLIB, DISP=SHR 


This statement assigns the COBOL subroutine 
library to the automatic call library. It 
must be specified if there is a possibility 
that the compiler may have generated calls 
to any COBOL library subroutines. See 
Appendix B for a list of library subrou- 
tines, their functions and entry points. 


USER-SPECIFIED DATA SETS 


Additional data sets may be defined for 
linkage editor processing. These data sets 
may be used as additional input sources of 
object modules or load modules. They may 
also be concatenated with the primary input 
data set or the automatic call library (see 
"Libraries"). 


Any number of data sets may be used for 
execution time processing. These data 
sets, or files, are identified in the 
source program, and each must be described 
by a DD statement. The ddname is used to 
link the DD statement to the COBOL state- 
ment in the source program that specifies 
the ddname. DD statement requirements for 
the DISPLAY, ACCEPT, EXHIBIT, and TRACE 
statements and for user-defined files are 
discussed in the following text. A DD 
statement ‘that specifies an abnormal ter- 
mination dump is also discussed. Use of 
the Sort Feature requires additional DD 
statements. For information about these 
Statements, refer to the chapter "Using the 
Sort Feature." 


THE DISPLAY STATEMENT 


The DISPLAY statement requires an asso- 
ciated DD statement unless the data is to 
be displayed on the console. The DD state- 
ments needed for each form of the statement 
are as follows: 


Example 1: 


data-name 


DISPLAY Mead \ ««eUPON SYSPUNCH 


//SYSPUNCH DD applicable parameters, i.e., 


4/7SYSPUNCH DD SYSOUT=B 


An unblocked data set and a logical 
record length of 80 characters are assumed. 
However, the programmer can specify a 
blocked data set by using the subparameters 
of the DCB parameter as follows: RECFM=FB, 
BLKSIZE=n*80, where n is the blocking fac- 
tor. SYSPUNCH must be on a device where 
blocking is permitted. For example: 


//S8YSPUNCH DD UNIT=SYSSQ, DCB= Xx 
11 (RECFM=FB, BLKSIZE=160), X 
17 LABEL=(, NL) 


Soe TS NT ED OS ae SS SS SD eS Se MS ee See 


Example 2: 
data-name 
DISPLAY )literal cet 


(SYSOUT is the default option) 


//SYSOUT DD applicable parameters, i.e., 


//SYSOUT DD SYSOUT=A 


An unblocked data set and a line width 
of 120 characters are assumed. However, 
the programmer can specify an alternate 
line width and/or a blocked data set by 
using the DCB parameter. To specify an 
alternate line width, the subparameters of 
the DCB parameter are used as follows: 


LRECL=line width+1,BLKSIZE=LRECL value. 


To specify a blocked data set, the subpar- 
ameters are used as follows: 


RECFM=FBA, LRECL=line width+t1, 
BLKSIZE=n* (LRECL value) 


where n is a blocking factor. SYSOUT must 
be on a device where blocking is permitted. 
The extra character in LRECL allows for the 
carriage control character. For example: 
To specify an alternate line width: 


7/SYSOUT DD SYSOUT=A, DCB=(LRECL=133, X 
4/ BLKSIZE=133) 


To specify a blocked data set: 


J/SYSOUT DD DSNAME=PRINTOUT, x 
4/ UNIT=SYSDA,..., X 
1/ DCB= (RECFM=FBA, xX 
1/1 LRECL=121, x 
J/ BLKSIZE=605), x 
// VOLUME=SER=111111 
Example_3: 
data-name 
DISPLAY \literal fees UPON mnemonic—-name 


where mnemonic-name is associated with the 
words SYSPUNCH or SYSOUT in the Environment 
Division. 


SYSPUNCH 
// \(SYSOUT 


\ DD applicable parameters 
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THE ACCEPT STATEMENT 


The ACCEPT statement requires an asso- 
ciated DD statement unless the data is 
being accepted from the console. The DD 
Statements for each form of the statement 
are as follows: 


Example _1: 
ACCEPT data-name 
(SYSIN is the default option) 


//SYSIN DD applicable parameters 


ACCEPT data-name FROM mnemonic-~name 


where mnemonic-name is associated with the 
word SYSIN in the Environment Division. 


//SYSIN DD applicable parameters, i.e., 


/ISYSIN DD * 
(data) 


An unblocked data set and a logical 
record length of 80 characters are assumed. 
However, the programmer can specify a 
blocked data set by using the subparameters 
of the DCB parameter as follows: RECFM=FB, 
‘BLKSIZE=n*80, where n is the blocking fac- 
tor. SYSIN must be on a device where 
blocking is permitted. For example: 


//SYSIN DD UNIT=2400,..., Xx 
tf DCB= (RECFM=FB, X 
17 BLKSIZE=160), X 
tl LABEL= (, NL) 


If a logical record length of other than 80 
characters is desired, it must be specified 
in the LRECL field of the DCB parameter. 


THE EXHIBIT OR TRACE STATEMENT 


The EXHIBIT or TRACE statement requires 
a SYSOUT DD statement as discussed for 
DISPLAY. 


Note: If the job step already includes a 
SYSOUT DD statement for some other use, 
another may not be inserted. 
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ABNORMAL TERMINATION DUMP 


To obtain a full abnormal termination 
dump in case the job is abnormally ter- 
minated, the following DD statement must be 
used: 


//SYSABEND DD applicable parameters, i.e., 


//SYSABEND DD SYSOUT=A 


USER-DEFINED FILES 


Files that are processed in a COBOL pro- 
gram must be described as data sets to the 
operating system. Whenever a file is spec- 
ified in a program by a 


SELECT file-name ASSIGN TO external-name... 


this file must be described in an FD file- 
name entry and in a DD statement in the 
execution-time job step. The ddname in the 
DD statement is the external-name specified 
in the ASSIGN TO clause. 


Note: The device-number clause of the 
SELECT statement is treated as comments by 
the compiler if an actual device number is 
specified. Actual device allocation is a 
function of the DD statement. 


FILE NAMES AND DATA SET NAMES 


In general, the term file, as used ina 
COBOL program, and the term data set, as 
used in operating system terminology, have 
the same meaning. There may be a dif- 
ference, however, between the file-name and 
the data set name. The data set name 
always represents a specific data set. The 
file-name can, at different times, repre- 
sent different data sets. The DD statement 
allows a programmer to select, at the time 
his program is executed, the specific data 
set that is to be associated with a partic- 
ular file-name. This facility can be espe- 
cially powerful when applied to input data 
sets. 


The file-name is a name known within the 
COBOL program. Changing a file-name 
requires changing input/output statements 
and recompiling the program. Changing a DD 
statement when a program is executed is a 
Simple procedure. 


As an example, consider a COBOL program 
that might be used in exactly the same way 
for several different master files. It 
might contain the clause SELECT MASTER 


ASSIGN TO *MASTERA'..e. In that case, the 
following DD statements, used at different 
times, would assign the different named 
data sets to the program: 


//MASTERA DD DSNAME=MASTER1,... 
//MASTERA DD DSNAME=MASTER2, e<« 
/7/MASTERA DD DSNAME=MASTER3, -«. 


If the first DD statement appears in the 
job step that calls for execution of the 
program, any reference within the program 
to MASTER is a reference to the data set 
named MASTER1; if the second DD statement 
appears, the reference is to MASTER2; if 
the third, the reference is to MASTER3. 


However, if a file-name within a program 
is always to be applicable to only a single 
data set, the names might be written as 
follows: 


SELECT TAXRATE ASSIGN TO ‘TAXRATE‘... 
The applicable DD statement might be: 


/7/TAXRATE DD DSNAME=TAXRATE, «ee 

Of the names, only the external-name 
that appears in the ASSIGN TO clause and 
the ddname of the DD statement must always 
be the same. The file-name and the data 
set name may be the same, or they may be 
different. 


SPECIFYING INFORMATION ABOUT A FILE 


Some of the information about the file 
must always be specified in the FD entry. 
Other information must be specified in the 
DD statement. For example, the amount of 
space allocated for a direct-access output 
file must be specified in the DD statement 
by the SPACE, SPLIT, or SUBALLOC 
parameters. 


Certain characteristics of files cannot 
be expressed in the COBOL language, and may 
be specified in the DD statement for the 
file by the DCB parameter. This parameter 
allows the programmer to specify informa- 
tion for completing the data control block 
associated with the file. (See “Additional 
File Processing Information" for a discus- 
sion of the data control block, and Appen- 
dix C for information about the fields of 
the data control block). 


Each file that is named by the SELECT 
clause requires the use of a file process- 
ing technique. Five processing techniques 
are discussed in this publication. They 


are the queued sequential (QSAM), basic 
sequential (BSAM), basic direct (BDAM), 
queued indexed sequential (QISAM), and 
basic indexed sequential (BISAM). 


THE FILE PROCESSING TECHNIQUES 


The file processing technique to be used 
is determined by the processing that is to 
be done on the file, the data organization 
of the file, and whether the data is 
accessed randomly or sequentially. The 
ORGANIZATION and ACCESS clauses of a COBOL 
source program determine the technique to 
be used. The information to be specified 
in the DD statement and in the FD entry 
depends on the technique used. Figure 8 
shows the permissible combinations of 
processing, data access, and organization; 
clauses in the source program that specify 
them; and the technique that is used for 
each combination. In addition, the record 
formats and characteristics for each tech- 
nique are listed. For additional informa- 
tion about the capabilities and restric- 
tions for each file processing technique, 
refer to the publication IBM System/360 


Operating System: Supervisor and Data 
Management Services, Form C28-6646. 


Files can be created only by use of 
QSAM, BSAM and QISAM. Files having fixed 
type records can be created with each of 
these access methods. Files having vari- 
able type records and undefined records may 
be created using QSAM or BSAM. 


In the following sections, the required 
and optional COBOL clauses and DD statement 
parameters for each file processing tech- 
nique are shown in figures. Included are 
discussions of special considerations for 
each technique. 


PROCESSING WITH QSAM 


Figure 9 shows the COBOL clauses that 
may be used with QSAM. Special considera- 
tions are as follows: 


1. The RESERVE clause can be used to 
specify more buffer areas, allowing 
overlap of input/output operations 
with the processing of data. If this 
clause is not used, additional buffers 
may be specified by using the BUFNO 
option in the DD statement. If no 
additional buffer areas are specified, 
two buffers are reserved by the 
system. 


Execution Time Data Set Requirements 49 


re a ne frantic ay aaa aera yee ee oS nee ee aa oe as 1 
| {Organization and | | | | 
| ; |Access Clauses | | | File | 
|File Processing jthat Define the | Permissible | Device | Processing | 
| Action | Processing |Record Formats |Requirements |Technique | 
|Write, read, and | ORGANI ZATION clause | Blocked] Unblocked |Direct. Access | QSAM : 
| update standard jis omitted. ACCESS }------- 4----~----- {Magnetic Tape| | 
| sequential file | SEQUENTIAL or |F,V {F,V,U |Unit Record | | 
| | ACCESS clause | ] | | | 
| jis omitted | | | ] | 
}~-------------------4------------------- }------- 4--------- }------------- 4-------------- { 
[Write and read a | ORGANIZATION | |F |Direct Access] BSAM | 
| direct-access file] RELATIVE | | | | | 
| with relative | ACCESS | | | | | 
{ record addressing | SEQUENTIAL | | | | | 
}--------------------}------------------- ------- 4------—-- {------------- }-------------- { 
|Read and update | ORGANIZATION l |F |Direct Access|BDAM | 
| a direct-access { RELATIVE | | | | | 
| file with relative|ACCESS | | j | | 
} record addressing | RANDOM | j { | | 
~-=-----------------}------------------- 4-------4---------4-------------}-------------- 
|Write and read a | ORGANIZATION | |F,U,V |Direct Access |BSAM | 
| direct-access File| DIRECT | j | | | 
] with relative | ACCESS | | | | | 
| track addressing ] SEQUENTIAL | | | | | 
}-------------------- 4------------------- 4------- }--------- 4------------- $------------ { 
|Read, update, and | ORGANIZATION | |F,U,V |Direct Access|BDAM | 
{| insert into a | DIRECT | ] | | | 
| direct-access file|ACCESS | | | | | 
| with relative | RANDOM | | | | | 
} track addressing | | | | | | 
}--------------------}------------------- }------- 4--------- $------------- }------------ | 
|Create a direct- | ORGANIZATION |F |F {Direct Access|QISAM | 
| access file with | INDEXED | | | | | 
J indexed sequential] ACCESS | | | | | 
} organization | SEQUENTIAL or | | | | | 
| | ACCESS cluase ] | | | | 
| | omitted | | | | | 
~------------------- 4-------------------4-------4--------- 4 ------------- f-------------- J 
| Read and update |] ORGANIZATION |F |F |Direct Access |QISAM | 
| a direct-access | INDEXED | | | | | 
| file with indexed |ACCESS | | | | | 
| sequential | SEQUENTIAL or | | | | | 
} organization | ACCESS clause | | | | | 
| | omitted | | | | | 
}-------------------- 4------------------- 4------- 4--------- 4------------- }------------ { 
|Read, update, | ORGANIZATION |F |F |Direct Access|BISAM | 
| and insert into | INDEXED | l | | | 
| a direct-access | ACCESS ] j | | | 
{ file with indexed | RANDOM | | | | | 
| sequential | | | | | | 
] organization | H ! | | | 

5 HEED ony oe OS Fae ee oN AS J 
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If WRITE AFTER ADVANCING is used, 


record size specified in the FD entry 


must allow for the carriage control 


character, 


but the character will not 


be printed or punched. For example, 
if the record size specified in the FD 
entry is 121, the actual record is 121 
characters; however, only 120 charac- 
ters will be printed or punched. 


Note: If the immediate destination of 
the record is a device that does not 
recognize a carriage control charac- 
ter, the system assumes that the con- 
trol character is the first character 
of the data. If WRITE AFTER ADVANCING 
is not used, the control character is 
treated as the first byte of data by 
the punch or printer. 


3. If the input device is the card read- 
er, RECORDING MODE IS F should be 
specified. If this clause is not spe- 
cified or RECORDING MODE IS V is spe- 
cified, the first eight bytes of the 
record will be interpreted as the con- 
trol bytes required for files with 
format V records. 


4. If QSAM files are on magnetic 
tape, the record block size should be 
at least 18 bytes. Shorter blocks 
will be treated as noise records. 


Figures 10 and 11 show the parameters in 
the DD statement that may be used with 
QSAM. All parameters except the DCB are 
described in “Format of the Job Control 
Statements." Additional DCB subparameters 
not shown in these figures are required for 
use of the sort feature. See "Using the 
Sort Feature" for information on these 
parameters. 


The DCB subparameters that can be speci- 
fied in the DD statement for QSAM files are 
as follows: 


DCB=[{DEN={0]1]| 2] 33] 
{, TRICH={C] E] T|ET}] 
{, PRTSP={0]1] 2] 33] 
[,MODE={C| E}] 
[, STACK={1] 23] 
{, OPTCD={W] C]WC}] 
{, BLKSIZE=integer] 
{, BUFNO=integer] 
{, EROPT={ACC]| SKP} ABE}] 


DEN={0]1] 2] 3} . 
can be used with magnetic tape, and 
specifies a value for the tape record- 
ing density in bits per inch as listed 
in Table 6. If no value is specified, 
200 bits-per-inch is assumed for 7- 
track tape, 800 bpi for 9-track tape 
without dual density and 1600 bpi for 
9-track tape with dual density. 


Table 6. DEN Values 

Oca ae ae TS ee ee ee 1 
| } Tape Recording Density j 
| | Bits-per-Inch | 
}------------------------------- { 
} | Model 2400 | 
ope ict toe eee Ss oe | 
{DEN value| 7 TRACK } 9 TRACK ] 
}--------- $----------------- 4------------- { 
| 0 | 200 | -- | 
| 1 | 556 | a | 
} 2 { 800 | 800 { 
| 3 | -- ! 1600 | 
Cea ae 1 Te aR ee NES OnE See Sa eS ee aa J 


TRTCH={CjE|T| ET} 
is used with 7-track tape to specify 
the tape recording technique, as 
follows: 


C - Specifies that the data-conversion 
feature is to be used; if data 
conversion is not available, only 
format-F and format-U records are 
supported by the control program. 

E - Specifies that even parity is to 
be used; if omitted, odd parity is 
assumed. 

T - Specifies that BCD to EBCDIC 
translation is required. 

ET- Specifies that even parity is to 
be used and BCD to EBCDIC transla- 
tion is required. 


PRTSP={0]1]2|3} 
specifies the line spacing on a print- 
er as 0, 1, 2, or 3. If PRTSP is not 
specified, 1 is assumed. 


The PRTSP subparameter is valid only 
if the unit specified for the file is 
a printer. It is not valid if the 
file is a report file, nor is it valid 
if WRITE...AFTER ADVANCING is speci- 
fied in the COBOL source program. 
Single spacing always is assumed for a 
printer unless other information is 
supplied. 


MODE={C | E} 
can be used with a card reader, a card 
punch or a card-read punch and speci- 
fies the mode of operation as follows: 
C - The card image (column binary) 
mode. 
E - The EBCDIC code. 


If this information is not supplied by 
any source, E is assumed. 


STACK={1] 2} 
can be used with a card reader, a card 
punch, or a card-read punch, and it 
specifies which stacker bin is to 
receive the card. Either 1 or 2 is 
specified. If this information is not 
supplied by any source, 1 is assumed. 


OPTCD={WjC|WC} 
requests an optional service provided 
by the system as follows: 
W - To perform a write validity check 
(on direct-access devices only). 
C - To process using the chained sche- 
duling method (see the publication 


IBM System/360 Operating System: 


Supervisor and Data Management 
Services, Form C28-6646). 


WC- To perform a validity check and 
use chained scheduling. 


If this information is not supplied by 
any source, none of the services are 
provided, except in the case of the 
IBM 2321 direct-access device where 
OPTCD=W is specified by the operating 
system. 
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Barbi me ea eer an ai ee Sg ea eee an re ere 
[ Type of OPEN | Input/Output | Required ] Other Required | | 
|] Statement | Statement | Key Clauses | Clauses | Optional Clauses | 
~-----------------}-------------------- 4-------------4~---------------4----~--------------------- 
| INPUT [REVERSED] i READ | Not | ASSIGN TO | BLOCK CONTAINS | 
| | AT END | permitted | LABEL RECORDS | RECORD CONTAINS | 
-------—~-------~---- 4-----~---~-----~~-~---- 4 | DATA RECORDS | RERUN | 
| OUTPUT | WRITE | | CLOSE | SAME AREA | 
{ | (AFTER ADVANCING] | | | RESERVE 
pao f-------------------- | }---------------- { REPORTS ARE | 
} I-o ] READ | | ASSIGN TO | USE (options 1, 2) 
| {| AT END | | DIRECT-ACCESS | Bee | 
| | REWRITE | | LABEL RECORDS | CLOSE LUNIT | 
| | | | DATA RECORDS | | 
| | | | CLOSE (UNIT) | | 
Pea oso ee tac ele FS onan ee pa eel ae nr ee Mtn oie cat ta as espe pe Sv Red nS ist i aa a J 
Figure 9. Permissible COBOL Clauses for QSAM 
Pearse i ama ea 5 ace era saa aad aaa Roe alas Poe e se se ee ee Se ee a 1 
| i | ! { | | I | | DCB | 
| [Device | | | | | | | }---------------- qo7-------- { 
| DSNAME| Type { UNIT] VOLUME|LABEL|SPACE|SUBALLOC| SPLIT] DISP jDevice Dependent |General l 
}------}-------- }----}------ +-----}-----}-------- 4-----4----~---------4----------------4---------- { 
| \Direct- |AS |AS J]SL |AS  |as | AS. een ,KEEP )|OPTCD=W, WC JOPTCD=C_ | 
| ] Access | | | | | | | (MODS ), PASS | | BLKSIZE 
| | }-------- 4----}------ $-----4-----4-------- t-----4 »CATLG ( }---------------- {BUFNO | 
| ] | | jsL | | | | »DELETE) | !EROPT=ABE | 
| ]Magnetic|AS |AS |NL  |NA [NA |NA | |TRTCH, DEN | | 
| | Tape | | |NSL | | | | | | 
[AS = f-------- t---- }------ }-----}-----4-------- -----4--------------4---------------- ---------- : 
| | | l | | | | | | PRTSP, [| EROPT=ACC | 
| [Unit JAS JNA |NL JNA  |NA {NA | SYSOUT=A | MODE, |(printer | 
| } Record | | | | | | l |] STACK | only) | 
| | , | | | | | | | | EROPT=ABE | 
}----- pal Rare eane! Bia En ih y Beer Ea doses sse nero (Eee aes ep Se WS en are pee ae epee 4 
JAS = Applicable Subparameters | 
JNA = Not Applicable | 
Ma a EI a a Nk ee Se ee J 
e¢ Figure 10. DD Statement Parameters Applicable to QSAM Output Files 
(=-= Poe Sa Lore SSS : aa : acai 2 nae > a aaa aa 1 Rone aaa 5 mma caninum aan Pane a 1 
| | | | | | | | | | DCB’ | 
| | | | | | | Po fen nnn nn = qrn------- : 
| [Device | ] | | | | | Device | | 
|DSNAME] Type | UNIT | VOLUME | LABEL] SPACE] SUBALLOC| SPLIT | DISP |Dependent |General | 
}------}-~------- $---------- 1-—---- }--~--}-----}-------- 4-----4---------------- 4---------4--------- { 
| {Direct- |not required if |SL [NA | NA JNA ] OLD , KEEP | JOPTCD=C | 
| ] Access |cataloged | | | | | , PASS I |BLKSIZE | 
| | See Seay SAS ae a eee +----- 4----- t-------- {----- { . CATLG }---------{ BUFNO 
| ]Magnetic|not required if [SL {NA [NA |NA | / UNCATLG| | TRICE, | EROPT= | 
| jTape | cataloged | NL | | | | » DELETE /|DEN |ACC,SKP | 
JAS { | {NSL | | | | | | ABE | 
| | | | | | | | | | | 
| t-------- }---------- 1------ 4-----4}-----4-------- femme 1 | 
| jUnit | Applicable] NA [NA [NA |NA {NA | MODE, | | 
| jRecord |Subparam- | | | | | | | STACK | | 
| I Jeters | | | ] | | | | | 
}~----- heat pare en es en) 5 renee dee ee fiance deferens Be oS a a ae hoses os oe er er 4 
JAS = Applicable Subparameters | 
|NA = Not Applicable 1 
eet ce eS ee eee ee Ses ee eee ewe eee ee en eee enaclt eee ee Sees J 


°® Figure i1. 
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DD Statement Parameters 


Applicable to QSAM Input and 1-0 Files 


Note: If the validity check is speci- 
fied, the system verifies that each 
record transferred from main storage 
to direct-access storage is written 
correctly. Standard recovery proce- 
dures are initiated if an error is 
detected. 


BLKSIZE=integer 
is used to specify the block size. 
This clause may be used only if BLOCK 
CONTAINS 0 RECORDS was specified at 
compile time. 


BUFNO=number of buffers 
is used to specify the number of buff- 
ers to be assigned to the file if no 
RESERVE clause is specified for the 
file in the source program. The maxi- 
mum number is 255. However, the maxi- 
mum number allowed for an installation 
is established at system generation 
time. 


EROPT={ACC| SKP| ABE} 
specifies the options to be executed 
if an error occurs in writing or read- 
ing a record as follows: 
ACC - To accept the error block for 
processing. 


SKP - To skip the error block. 
ABE - To terminate the job. 
There are two cases when the sub- 


parameter can be specified: 


e If no error processing declarative 
(USE sentence, option 2) is 
specified. 


e If an error processing declarative 
is specified with a normal return. 


If no option is specified, ABE is 
assumed. 


Processing with _BSAM 


Figure 12 shows the COBOL clauses that 
may be used when processing with BSAM. 
Special considerations are discussed below. 


RELATIVE TRACK ADDRESSING: For files 
created by the use of BSAM with relative 
track addressing the compiler ensures that 
each track, on which a record is written is 
completed as required by the operating sys- 
tem. (The DD statement specifies the 
amount of space to be allocated to the 
file.) 


F-type Records: For files with F-type 
records, the compiler generates instruc- 
tions to specify that dummy records be 


written to complete the track. These dummy 
records are written by the system and con- 
tain a configuration of all 1s in the first 
byte of the symbolic key field. They ind- 
icate to the system that a record can be 
added to the file in the space allocated to 
the dummy record. Since these records are 
system-generated, the programmer should not 
write records that include a symbolic key 
field containing such a configuration in 
the first byte of the field. 


U-type or V-type Records: For files con- 
taining U-type or V-type records, capacity 
records are written to complete the track. 
A capacity record is a record which signi- 
fies that a track has been completed. The 
number of tracks thus filled will determine 
the space available for inserting records 
at a later time. Records are inserted, or 
added, by replacing dummy records or alter- 
ing capacity records. Once the file is 
created, more space cannot be allocated; 
the extent of the file cannot be increased. 


Note: For input files containing V-type 
records created by the use of BSAM with 
relative track addressing, capacity records 
are not made available, 


The FILE-LIMIT Clause: If the FILE-LIMIT 
clause is specified, the number stated in 
this clause determines the number of tracks 
that are prepared with dummy or capacity 
records for the file. This clause may be 
used to ensure that sufficient space will 
be available for a file in which records 
will be inserted at a later time. If the 
FILE-LIMIT clause is not specified, the 
number of tracks used may be determined, at 
the end of file processing, from the data- 
name specified in the ACTUAL KEY clause. 
The number of tracks is the value plus 1. 


Releasing Unused Tracks Once a BSAM out- 
put file has been closed, records cannot be 
added to those tracks that were allocated 
but unformatted (prepared with dummy or 
capacity records). These unformatted 
tracks must be released by specifying the 
RLSE option in the SPACE parameter of the 
corresponding DD statement. This is done 
so the tracks will not be counted as part 
of the file. 


Note: To release all of the unused tracks 
on the last volume, space must have been 
requested in track or block units (by the 
SPACE parameter). If the CYL subparameter 
was specified, the unused tracks of the 
last partially written cylinder are not 
released. If the file is then opened as a 
BDAM file with direct organization and with 
the APPLY RESTRICTED SEARCH option speci- 
fied, these unused, unformatted tracks are 
searched and counted even though they do 
not contain any accessible records or 
space. 
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RELATIVE RECORD _ADDRESSI For files 
created by the use of BSAM with relative 
record addressing, the compiler generates 
instructions to add dummy records to com- 
plete the last track of the file when it is 
closed. These records are compiler- 
generated and contain a configuration of 
all 1s in the first byte of the record. 
Since these records are not system- 
generated, the user can write records with 
this configuration in the first byte of the 
record. In this manner, space can be 
reserved for later additions to the field. 


a ee ee ee ee ee ———— 


addressing, no KEY clause is used. For 
BSAM with relative track addressing, the 
SYMBOLIC KEY clause is always required; the 
ACTUAL KEY clause is required only for out- 
put files. The SYMBOLIC KEY clause speci- 
fies a data-name that contains the record 
identifier. The ACTUAL KEY clause speci- 
fies a data-name that contains the relative 
track number on which the record currently 
being written is placed. The value of the 
data-name advances sequentially as space on 
the current track is used up, or as the 
programmer adds to it. The first track of 
a BSAM file is: track number=ACTUAL KEY 
number=0. The second track number is 1. 
The SYMBOLIC KEY and ACTUAL KEY clauses 
must never be defined in any file or in the 
Linkage Section. 


CHECKING FOR DUMMY RECORDS: If an input 
file containing F-type records was created 
by the use of BSAM with either relative 
track or relative record addressing, any 
dummy records in the file will also be made 
available. The programmer can recognize 
these records by testing for the presence 
of the figurative constant HIGH-VALUE in 
the first position of the record (relative 
record) or of the symbolic key field (rela- 
tive track). 

CREATING MULTI-VOLUME DATA SETS: The COBOL 
programmer may create multi-volume data 
sets for BSAM files with relative track or 
relative record addressing by means of the 
CLOSE REEL or UNIT statement. When this 
statement is executed, the current extent 
is initialized, volume-switching procedures 
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are executed, and for relative track 
addressing, the contents of ACTUAL KEY are 
updated to reflect the relative track 
number of the last track on the old volume. 
The primary, and as many secondary alloca- 
tions as possible, are normally given to 
the first volume (up to 16 extents per 
volume), and subsequent volumes are allo- 
cated from the secondary specification. 


Since all records of a file created 
using relative record addressing must be 
created by the COBOL programmer, he may 
choose to permit volume switching to occur 
automatically. However, this procedure | 
does not guarantee a specific distribution 
of records over the volumes, the placement 
of a particular record on a particular 
volume, or whether the data set is in fact 
multi-volume. 


To create a file with records distrib- 
uted as evenly as possible over several 
volumes, the programmer must calculate how 
much space his file will require (see 
Tables 7, 8, and 9) and divide by the 
number of volumes. The result of this cal- 
culation (rounded) should be specified as 
both the primary and secondary allocation 
of the SPACE parameter of the associated DD 
statement. The programmer should execute 
CLOSE REEL or UNIT before the end of the 
initially allocated space on the first 
volume (that is, execute the CLOSE REEL 
before writing the record which he wants to 
be first on the second volume). 


For example, to distribute 2150 80-byte 
records as evenly as possible on three 2311 
volumes, 34 tracks per volume are required 
and the SPACE parameter should specify 
(34,34). After writing the 714th record, 
the programmer should execute CLOSE REEL or 
UNIT and continue writing. 


When using relative record addressing, 
if the programmer overestimates the . 
required space and the records do not fill 
the last track(s), the compiler will write 
dummy records. These records are included 
in the relative record count and the pro- 
grammer must be aware of this when trying 
to address records on subsequent volumes. 


Table 7. Direct-Access Device Overhead Formulas 

(Se reas sss === ey ae a we ee ee a eae ee 1 
| | Bytes Required by Each Data Block | 
| ea ae ao nea ae en clare Parsee Sea ew ae eee Sn eer ea { 
| Device 1 Blocks With Keys | Blocks Without Keys | 
| besos ero eser rare | Seared cele aa 1 ease an a gana aca { 
] | Bi | Bn | Bi | Bn 
[------------ $~---------------------- 4-------------- 4------------------ }---------------- { 
] 2311 | 81+1.049(KL+DL) | 204+KL+DL | 61+1.049 (DL) | DL | 
| 2314 | 1464+1.043(KL+DL) ] 45+KL+DL | 101+1.043(DL) | DL | 
! 2302 H 81+1.049 (KL+DL) | 20+KL+DL | 61+1.049 (DL) | DL | 
| 2303 | 146+KL+DL | 38+KL+DL | 108+DL | DL 
| 2301 | 186+KL+DL | 53+KL+DL | 133+DL | DL | 
| 2321 | 100+1.049(KL+DL) | 16+KL+DL | 84+1. 049 (DL) | DL | 
}---------~-- BRE g eae a eee nae a ee he Scenics ce A Sorensen kl ee aes ae ane a A a i ene aa ere | 
]Bi is any block but the last on the track. | 
|Bn is the last block on the track. | 
}DL is data length. | 
{KL is key length. | 
UE cee re We Ot ee tel nro POR Ee ced nc Ee MR as EO EE ree PIRI ae ee Pe AE eI Oe a J 
Table 8. Direct-Access Storage Device Capacities 

CS ee Mo pee ee oes oe ee = eee ee eer ae ee ee i ate arate ec ee ae topo 
| Device { Volume | Track | ] No. of } Total | 
| Type ] Type | Capacity* |Tracks per Cylinder] Cylinders | Capacity* | 
[-~--------- }----------- }------------- 4------------------- }-----~-------- frn-2-2-------- { 
| 2311 | Disk | 3625 | 10 | 200 | 7,250,000 | 
| 2314 | Disk | 7294 | 20 | 200 | 29,176,000 | 
| 2302 | Disk | 4984 | 46 | 246 | 56,398,944 | 
] 2303 | Drum | 4892 ] 10 | 80 [ 3,913,600 | 
| 2301 | Drum | 20483 | 8 ] 25** | 4,096,600 | 
| 2321 J Cell | 2000 | 20**+ | 980*** | 39,200,000 | 
| ee ee E Beeapense eae ecaprr mee bee en es ayer Lise oeeaueeeearoSs pipe eae ae epee Poe ee ue 4 
{ *Capacity indicated in bytes. | 
| **There are 25 logical cylinders in a 2301 Drun. | 
{ ***#A volume is equal to one bin in a 2321 Data Cell. | 
We a a a a a a as Se See ee a eS ee ee eS 4d 


If the programmer underestimates the 
Space required, automatic volume switching 
may occur before the CLOSE REEL or UNIT is 
executed, since space on the first volume 
is filled. If this has happened, the CLOSE 
REEL or UNIT will start a third volume. 


If no secondary allocation has been 
specified and the programmer issues a CLOSE 
REEL or UNIT statement, the job will ter- 
minate abnormally, since the allocation of 
subsequent volumes is taken from the secon- 
dary allocation field of the SPACE 
parameter. 


Note: In the creation of a BSAM output 
file, performance is improved by specifying 
the CONTIG subparameter of the SPACE param- 
eter in the DD statement. However, space 
allocation is more efficient if CONTIG is 
not specified. 


To determine the amount of space a data 
set requires, the following variables 
should be considered: 


e Device type 

e Track capacity 

e Tracks per volume 

e Cylinders per volume 

e Data length (block size) 
e Key length 

e Device overhead 


Device overhead refers to the space 
required on each track for hardware data, 
is,e., address markers, count areas, gaps 
between records, Record 0, etc. Device 
overhead varies with each device and also 
depends on whether the blocks are written 
with keys. The formulas in Table 7 may be 
used to compute the actual space required 
for each block, including device overhead. 


Table 8 lists device storage capacity, 
and Table 9 lists capacity in records per 
track for several direct-access storage 
devices. 
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Programmers requiring more detailed 
information on direct-access storage 
devices may refer to the publication I 
System/360_ Component Descriptions -- 

2841 Storage Control 
2302 Disk Storage, Models 3 and 4 
2311 Disk Storage Drive, Model 1 


2321 Data Call Drive 


Se ee ee ie ee ee ee eS eS ST eS a ee US ele 


2303 Drum Storage, 


eS SS Se 


Form A26-5988. 


BSAM PARAMETERS AND _SUBPARAMETERS: Fi 
13 and 14 show the parameters that may 
used in a DD statement when processing 
BSAM. BSAM files must be on direct-ac 
devices. Therefore, the UNIT, VOLUME, 
SPACE parameters that specify direct-a 


Table 9. Direct-Access Device Track 
(ees Sr Rare ee ee Sa oe T 
| Maximum Bytes per Record | 
{ Formatted without Keys { 
¢-—----y-----1-----1----- ----- 7----+= 
} 2311] 2314] 2302] 2303] 2301] 2321] 
{ 3625) 7294! 4984] 4892] 20483} 2000] 
|} 1740] 3520] 2403| 2392}10175| 935] 
] 1131] 2298] 1570] 1558] 6739] 592| 
| 830] 1693] 1158] 1142] 5021] 422| 
{ 651) 1332] 912] 892} 3990] 320] 
}-----+-----}----- $-----}-----}------}------------ 
{| 532] 1092] 749{ 725} 3303] 253] 
1} 4&7] 921] 634] 606f 2812} 205] 
| 384} 793] S46] 517] 2444] 169] 
{ 334] 694) 479] 447] 2157] 142!) 
|} 295] 615], 425] 392] 1928] 119] 
| earns Speers Ieee Seeger Cnenraeen (ee etea ware Se epeNnielise ear sm eee eye cee 
} 263[ 550}, 381] 346] 1741] 101] 
| 236] 496] 344] 308] 1585] 86 | 
} 223] 450] 313] 2764] 1452) 73 
{ 193] 411, 286] 249] 1339] 62 | 
] 177) 377) i164] 225] 1241] 53] 
}-----4-----+-----4----- $-----4------4------~----- 
} 162, 347] 244] 204) 1155] 44 
} 149] 3241, 225f 186] 1079] 37) 
| 138] 298] 209] 169] 1012] 30} 
| 127] 276] 196{ 155] 952} 24] 
} 118] 258] 183] 142] 897] 204 
|-----}-----}----- 4-----}-----4------}------------ 
| 109} 241] 171) +4130] 848) 15] 
|} 102} 226] 161] 119] 804] 10] 
| 95] 211} #%4151) 109] 763] 6] 
| 88} 199] 143] 100| 7264 | 
| 82] 187}, 135] 92| 691] | 
}-----4----- 4-----}-----}-----}------ 4 
| 77| 176| 127] 84| 659] | 
| 72| #166) 1214 77} 630] | 
| 67) 157} 114] 70} 603} | 
| 63] 148] 108] 64] 577] j 
| 59{ 139] 102] 58], 554] ] 
eee Seen fee el Lee acer ae Rae ele i 
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devices must be used when creating the 
file. However, note that the SPLIT param- 
eter cannot be used. 


The DCB subparameters for BSAM are as 
follows: 


1. The DSORG=DA subparameter must always 
be specified for COBOL for files 
created by use of BSAM. 


2e The subparameter OPTCD={W} is used to 
request a service provided by the con- 
trol program. The subparameter is 
discussed under QSAM DCB 


subparameters. 
a i Sa . i NEA aC 1 
] Maximum Bytes per Record | 
s J Formatted with Keys | 
fss-= 5 eee ; rare : ae Geen beeen eae: { 


T we Bi 
2311] 2314] 2302] 2303] 2301{ 2321] 


| 
Hl asasepiamhl (Eecaeiy. cuimenesigr ate Sauna 4-2=-==f--==- 
{ 3605] 7249| 4964] 4854| 20430] 1984] 
| 1720| 3476] 2383] 2354] 10122] 920] 
| 1144] 2254] 1505] 1520] 6686] 576] 
} 811] 1649] 1139] 1104] 4968] 406] 
| 632{ 1288] 893] 854| 3937] 305] 
ee fo----4------4----- 
} 512] 1049] 730] 687] 3250] 238] 
{ 428! 877] 614] S68| 2759] 190] 
|} 364{ 750] 527] 479] 2391] 154] 
| 315| 650{ 460] 4O9| 2104] 126] 
| 275| 571} 406] 354] 1875] 103] 
4-----4-----4------ a ne one { 
{ 244] 506] 362] 308| 1688|{ 85] 
| 217] 452] 325] 270] 1532] 70| 
{ 194] 4O7] 294, 238] 1399{ 58] 
j 174{ 368] 267] 211] 1286{ 47] 
} 158{ 333f 245| 187] 1188] 38] 
4 gee ee ee he eee oe ee he eS 
| 143] 304] 224, 166] 1102] 29] 
{ 130] 277) 206] 148{ 1026j 21) 
| 119] 254, 190] 131] 959} 15] 
} 108] 233] 176) 117] 9899] 9 | 
1 99] 215] 163] 104) 844] | 
4-----4----- f------ fo----$------4----- { 
|} 90[ 198{ 152] 92{ 795] l 
} 82] 183] 142] 81) 751] l 
| 76{ 168] 132] 714 710] l 
|} 69{ 156{ 123) 62] 673] l 
} 63] 144} 116[ S4] 638] | 
, aes cc aatoth, ex tacoma: eteran +------4---=- { 
| 58] 133] 108] 46] 606] l 
{| 53] 123] 102{ 39] 577{ l 
| 48{ 114} 95, 32] 550] | 
|} 44] 105] 89] 26{ 524| | 
} 40] 96] 83] 20] 501] l 
peepee Sates eae L_-..—— Losses 2 ee ee Losses J 


a yee ae ee ee a aS nea ey ho me ye eae See Me a ge pees SPN he ela ay, wg he a oe) ee oe 7 


| [type of OPEN] Input/Output | Required Jother Required | | 
{ Organization] Statement j Statement |Key Clauses |Clauses |Optional Clauses | 
| DIRECT | INPUT | READ | SYMBOLIC KEY|ASSIGN TO |RECORD CONTAINS | 
| | | AT END | | DIRECT-ACCESS]USE (option 2) 
a 4--~--~------- 4------------ {LABEL RECORDS |FILE-LIMIT | | 
| | OUTPUT | WRITE | SYMBOLIC KEY| ARE STANDARD | (with output files) | 
| | ] |ACTUAL KEY |DATA RECORDS |CLOSE | | 
| | { | | CLOSE | REEL | 
| | | | | | 
 SREaGUR ELE to ee | beim uarnas 1 =e S | GIS EEE | 
| RELATIVE | INPUT | READ Not | |RECORD CONTAINS | 
j } AT END | permitted | | SAME AREA 
) 00 Peete nen aenn--- 4------------ 4 | JUSE (option 2) | 
] ] OUTPUT | WRITE | | | CLOSE ieee | 
I | | | | REEL | 
| { i | | | 
Liceoeoeosto se ieotesosoess= 2 eee ne ee i epee eee, MS Soe Sa ae ee a a aes need apenas eae oe J 
Figure 12. Permissible COBOL Clauses for BSAM 
oe oe eo cae Gara a a= ToS > {oS Tea 2 desler Te 5 aaa tae alan gs aac ame 1 
| | | | | | | | | DCB | 
| | oe | ie | }--------7--------- 
|DSNAME|Device |UNIT|VOLUME|LABEL] SPACE] SUBALLOC] SPLIT] DISP [Required |optional | 
|------4-------- 4----4}------ }-----4-----}-------- 4-----}-------------4--------}--------- { 
|AS |Direct- JAS |AS {jsL |AS~ fas |NA | NEW(,KEEP ) | DSORG=DA]OPTCD= {Ww} | 
| |Access | | | }RLSE4 | { | ,CATLG [| | | 
| [required] =| | | | | | /PASS (| | | 
| | i | | l | | »DELETE) | | | 
| | | | | l | | | | | | 
| | | | | | | | |Note: MOD not] | | 
| | | | | | I jmeaningful | | 
 eereeane 5 ener meres Senses See eran B earns 5 enya f arene eee nae Weds eee et caer 2 areas eee ae = 4 


{AS = Applicable subparameters | 
JNA = Not applicable | 
{+For direct organization only | 


Figure 13. DD Statement Parameters Applicable to BSAM Output Files 


Se ee ee ee Oe a ae ee ry er I 
|DSNAME | Device ] UNIT | VOLUME | LABEL | SPACE, SUBALLOC, SPLIT | DISP | DCB | 
}------ 4-------- }----1------- 4-----4---------------------------- 4---------------- 4------ { 
J AS jDirect- |not required|SL | NA | OLD /,PASS | NA | 
] |Access jif cataloged| | | , KEEP | | 
| | required | | | ] ,CATLG | | 
| | | | | | ; DELETE | | | 
| | | | | { , UNCATLG) | | 
———— i eaeeecenen teers penetra receear ies es Eee : Fee Xe Aa eee Pe et ee es Aye ee Meteepsat es | 
{AS Applicable subparameters | 


| NA = Not applicable | 


Figure 14. DD Statement Parameters Applicable to BSAM Input Files 
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Processing with BDAM 


Figure 15 shows the COBOL clauses that 
May be used with BDAM. Special considera- 
tions are as follows: 


1. For BDAM with relative record address- 
ing the SYMBOLIC KEY is required. It 
contains the relative record number 
(or position within the file) of the 
record to be read or rewritten 
(updated). (For BSAM with relative 
record addressing, the position of the 
logical records ina file is deter- 
mined relative to the first record of 
the file, starting with the initial 
value of zero.) The WRITE verb is not 
allowed for relative record address- 
ing, because the extent of the file 
cannot be increased. 


2. For BDAM input files with relative 
track addressing, the ACTUAL KEY 
clause is used to locate the track on 
which the search for the record is to 
begin. The SYMBOLIC KEY clause is 
used to identify the location of the 
record on the track. 


3. For BDAM I-O files with relative track 
addressing, the ACTUAL KEY clause is 
used to locate the track on which the 
search begins for space to insert a 
record for the WRITE verb and to 


locate a record for the READ verb. 


Note: The programmer may wish to build a 
BDAM file with relative track addressing in 
a random manner. In COBOL, however, the 
tracks of the file must first be formatted 
using BSAM. This can be done by opening 
the file as output and specifying the FILE- 
LIMIT clause for the file. The programmer 
only need open and close the file, and the 
necessary capacity or dummy records will be 
written on the number of tracks specified 
in the FILE-LIMIT clause. The programmer 
can then open the file as I-O and proceed 
to build his file using BDAM. 





Figure 16 shows the DD statement parame- 
ters that may be used with BDAM. Note that 
the SPACE, SPLIT, SUBALLOC, and DCB parame- 
ters are not applicable. 


Processing Indexed Sequential Files with 
QISAM and BISAM 


Figures 17 and 18 show the DD statement 
parameters that may be used with QISAM out- 
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Indexes: 


put files and QISAM and BISAM input and I-0O 
files. Note that the SUBALLOC and SPLIT 
parameters are not applicable for any of 
these files. 


FILE ORGANIZATION: An indexed sequential 
file is one in which records are arranged 
on the tracks of a direct-access device in 
a sequence determined by keys. The key 
normally is a control field that is an 
intrinsic part of the information in the 
record. (e.g., the part number), and is 
specified by the RECORD KEY clause in the 
source program. Records are written or 
read by the use of indexes. These indexes 
provide flexibility in that the programmer 
cans 


e Write and later read or update logical 
records in a sequential, ascending 
order (using QISAM) based on the 
collating sequence of the keys. This 
is done in a manner similar to that for 
sequential organization. 


e Read or update individual logical 
records in a random manner (using 
BISAM). This method is somewhat slower 
per record than reading according to a 
collating sequence, since a search for 
pointers in indexes is required for the 
retrieval of each record. 


*# Insert new logical records at any point 
within the file (using BISAM). Using 
the indexes, the system locates the 
proper position for the new record and 
makes all necessary adjustments so that 
the order of the records, according to 
the keys, is maintained. 


There are two basic types of in- 
dexes, track indexes and cylinder in- 
dexes. There is one track index for each 
cylinder in the prime area (see "Indexed 
Sequential File Areas" for a description of 
prime area). The track index is written on 
the first track of the cylinder that it 
indexes. An entry in the track index con- 
tains the identification of a specific 
track in the cylinder and the highest key 
on that track. 


There is one cylinder index for each 
file in which prime area data takes up more 
than one cylinder. The cylinder index con- 
tains one entry for each cylinder in the 
prime area, each entry pointing to the 
track index in a particular cylinder. 


ance EE AON ene Rae SE SRY RIOR a EFFORT SS NOTRE eR Se ret ae RO ne ey per tee aoe a a eh ene NE 4 
j organi- ] Type of OPEN| Input/Output {Required other Required] | 
]zation |Statement jStatements |Key Clauses |Clauses jOptional Clauses | 
|--------}------------}--------------4------------4--------------4---------------------- { 
{DIRECT |INPUT | READ | SYMBOLIC KEY|]ASSIGN TO {RECORD CONTAINS 
| | ] CINVALID KEY] ]ACTUAL KEY | DIRECT-ACCESS|SAME AREA | 
{ }------------ 4.-----------_~ 4 {LABEL RECORDS JAPPLY (option 1) | 
| | I-O } READ | |} ARE STANDARD |USE (option 2) | 
| | | WRITE { {DATA RECORDS | | 
| | | REWRITE | | CLOSE | 
| | | (INVALID KEY] } | | | 
|--------+------------}--------------}------------ { fen nnnna=-------------- { 
| RELATIVE| INPUT ] READ | SYMBOLIC KEY| |RECORD CONTAINS 
| | | {INVALID KEY] | | |SAME AREA | 
| ------------- 4-------------- { | | SAME AREA | 
| | I-o } READ | | JUSE (option 2) | 
| | | REWRITE | | | | 
| | } (INVALID KEY] | | | 
eee se Aieeeiieh ened e ee eee ae eee ee ee ee ee a 
ores 15. Permissible COBOL Statements for BDAM 
Rte ee ee gn he ee ee he ee ee ee ee ae oe tT 74 
| DSNAME |Device 1 UNIT i VOLUME } LABEL] SPACE, SUBALLOC, SPLIT| DISP | DCB | 
~------------- 4-=~-----}----1-------4-----4--------------- === 4-2-2 == === f= 
| Applicable {Direct- |not required|SL | NA | OLD ,» PASS [NA | 
{subparameters [Access ]if cataloged] | | , KEEP | | 
| | Required] | | | , CATLG | | 
| | | wl [roxcarus 1 | 
| i | | | | #DELETE / {| | 
bee BO oe en Se ee Loo aes Sa eS Beet as rae 4-4 
JNA = Not Applicable | 
J 


Figure 16. 


If the file is being read randomly, the 
system locates the given record by its key 
after a search of a cylinder index and the 
track index within the indicated cylinder. 
If the file is being read sequentially 
starting with the first record, no index 
search is necessary. 


Indexed Sequential File Areas: The pro- 


grammer specifies the structure of an inde- 
xed file and space to be allocated for it 
in the DD statement for the file when the 
file is created. In some instances, more 
than one DD statement is required. (These 
DD statements are described in "Using the 
DD Statements -- Single Volume Files.") The 
space being allocated must be divided into 
one, two, Or three areas, depending on the 
needs of the programmer. These areas are: 
prime area, index area, and overflow area. 
The overflow area is optional. 


Prime Area. The prime area is the area in 
which data records are written when the 
file is created or reorganized. These 
records are in a sequence determined by the 
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record keys. The track indexes also use a 
portion of the reserved prime area. To 
reserve prime area space so that new logic- 
al records may be inserted without forcing 
records into an overflow area (described 
below), dummy records may be written when 
the file is being created. Dummy records 
are described later in "Processing with 
QISAM: Creating Indexed Sequential Files." 
The prime area may Span multiple volumes 
and may consist of several noncontiguous 
areas. 


Index Area. The index area contains the 
cylinder indexes and, if requested, master 
indexes (described later) for the file. 
This area exists for any file that has a 
prime area on more than one cylinder. 

Space for this area will be allocated 
separately from the prime area if specific- 
ally requested. The index area must be 
contained within one volume, but that 
volume need not be the same device type as 
the prime area volume. If not specifically 
requested, the index area will automatical- 
ly be constructed in the independent over- 
flow area, or, if none, in the prime area. 
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poooe ee qo----------------- +. ----- +--+ 
| Parameter | Applicable Subpzrameters l 
}--------- }---~--------------------------- { 
| ddname {ddname used only for first DD | 
| {| statement of each file. | 
}--------- }--------~--=--~----=----------- { 
|DSNAME2 | jeeuete! (INDEX) | 
| | (&name (PRIME) | | 
| | (OVFLOW) | 
}---------}------------------------------- { 
| Device |Direct-access required ] 

---—--- }-------------------------------{ 
| UNIT |DEFER not permitted { 
~-------- }-------------------------------| 
| SEP |Restricted, see "Job Control | 
{AFF | Procedures" | 
-~------- }-~-----------------------------] 
| VOLUME ] Volume sequence number sub- | 
| | parameter not applicable { 
}---------}------------------------------- { 
| LABEL {SL | 
nS Ste a Se ee ie 4 
| SPACE { CYL, (,, CONTIG] ABSTR | 

asa eases Ue at ae Re re a ate 4 
 SUBALLOC |Not applicable | 
Bh Sl i a ea ee et 4 
|} SPLIT {Not applicable 
a ee Neat a oye 4 
{DISP | KEEP | 
j | NEW2| , PASS | 
| , DELETE i 
[--------- }------------------------------- { 
{DCB | Required: | 
| | DSORG=IS | 
| 
i 1Optional: { 
| | BUFNO=xxx | 
| | BLKSIZE | 
| } OPTCD=(WJ (M) CY] CI] {RI | 
}-------~- 1_---------~------------------- { 


| l 
| elements must be in this order | 
|2MOD not meaningful. CATLG allowed only | 
] if all areas are allocated with a single] 
{ DD statement | 
{?The DCB. parameter should be the same for] 
| each DD statement | 
L 


DD Statement Parameters Applic- 
able to QISAM Output Files 


Figure 17. 


Overflow Area. The overflow area is the 
area in which space is allocated for 
records forced from their original (prime) 
tracks by the insertion of new records. 
The fact that some records are stored in 
these areas, physically out of sequence, 
does not change the ability of QISAM to 
read the file in a logical sequence. An 
overflow area need not be specified if 
records are either not going to be added to 
the file, or sufficient space has been 
reserved by writing delete records in the 
prime area. 


There are three ways in which space for 
an Overflow area may be allocated: 
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1. Space may be requested for an indepen- 
dent overflow area, using the dsname 
(OVFLOW) DD statement, either on the 
same volume or on a separate volume of 
the same device type as that of the 
prime area. 


2. Tracks on each cylinder can be re- 
served to hold the overflow of that 
cylinder (cylinder overflow option). 


3. If the prime area is not filled when 
the file is created, the remaining 
Space will be designated as an inde- 
pendent overflow area, even though it 
is not requested directly. 


Additional information about indexed 
sequential file structure is contained in 
the publication IBM System/360 Operating 


SEQUENTIAL FILES: The structure of an 
indexed file and the space to he allocated 
is specified in the DD statement(s). The 
space can be subdivided and allocated in 
several. different ways; the allocation 
specified on the DD statement(s) must be 
sufficient for all the areas used. 


QISAM DD Statement Requirements: The spe- 


cial parameter requirements for DD state- 
ments that define new indexed sequential 
files are discussed below. The discussion 
is oriented to indexed sequential files on 
one volume. Many of the parameters used 
for creating multi-volume files are not 
discussed here. For more detailed informa- 
tion about parameters for both single and 
multi-volume files, see the publication IBM 
System/360_ Operating System: Job Control 
Language, Form C28-6539. 


ddname (name field) 
The name field of the first or only DD 
statement defining the indexed sequen- 
tial file can contain the symbolic 
identification "*ddname' or procstep. 
ddname. Succeeding DD statements for 
the file must not be named. 


DSNAME | 
This parameter must be specified and 
is coded as follows: 


dsname 
DSNAME= l&name jf { (element) ] 


The first subparameter, dsname or 
name, must be the same in all the DD 
Statements defining one data set. The 
element subparameter, INDEX, PRIME, or 
OVFLOW, indicates the type of area 
defined by the DD statement. If more 
than one DD statement is used to 
define a file, the order in which the 
statements should be placed in the 
input stream is as follows: 


DD DSNAME=dsname (INDEX) 
DD DSNAME=dsname (PRIME) 
DD DSNAME=dsname (OVFLOW) 


Deviation from this order results in 
abnormal termination of the job. If 
the element subparameter is omitted, 
PRIME is.assumed. Note that an 
indexed sequential file cannot be 
specified by statements containing 
only index and overflow elements. 


SPACE 


SPLIT 


DISP 


This parameter specifies the space to 
be allocated for each of the separate 
areas on the device, and must be 
included. Only cylinder (CYL) or 
absolute track (ABSTR) requests are 
permitted, and with ABSTR the desig- 
nated tracks must encompass an 
integral number of cylinders. All the 
DD statements defining one indexed 
sequential file must specify the same 
subparameter, either CYL or ABSTR. 
When all the DD statements specify 
CYL, all must also specify or omit 
CONTIG, depending on whether the space 
allocated is to be contiguous or non- 
contiguous. The directory or index 
quantity subparameter of the SPACE 
parameter is used to request the 
number of cylinders to be allocated 
for an index area embedded within the 
prime area (see “SPACE Parameter" in 
the section entitled "Job Control Pro- 
cedures"). An embedded index resides 
in the middle of a track and saves 
searching time by first determining 
which half of the track contains the 
requested record. 


This parameter should never be speci- 
fied for a QISAM file, either for 
sharing a cylinder with QISAM files or 
for sharing it with a QISAM file and 
another type of file. 


This parameter is written as it would 
be for any new file that cannot be 
cataloged. The CATLG subparameter 
must not be specified unless only one 
DD statement is used to allocate the 
file space. (See "Cataloging Files" 
for additional information about cata- 
loging indexed sequential files.) 


foe aS ep a ee 1 
| Parameter | Applicable Subparameters | 
{-------~--4------------------~----~----~--- { 
|ddname {ddname used only for first DD | 
| ] statement of each file | 
f--------- $-----~------------------------- { 
|DSNAME+ |dsname | 
Tamarac Tae eee ae enone { 
| Device |Direct-access required | 
--------- ---~---------------------------| 
| UNI T2 |Applicable subparameter | 
--------- 4-------------------------------4 
| SEP |Restricted, see “Job Control | 
| AFF | Procedures" | 
—--------+4----~-----~---------------------- 5 
|] VOLUME JApplicable subparameters | 
--------- $--------------~-~----~---------| 
{ LABEL |SL 
--------- -------------------------------4 
] SPACE |Not applicable | 
--------- 4-------------------------------| 
{SUBALLOC {Not applicable | 
~-------- f-------------------------------] 
) SPLIT {Not applicable | 
~---~---- $-------------------------------{ 
|DISP | » PASS | 
| | OLD?] , KEEP | 
| | » DELETE | 
j--------- 4------------+------------------ { 
| DCB |Required: DSORG=IS | 
| | | 
| JOptional: BUFNO=xxx (not | 
j | allowed for BISAM) | 
j--------- 4------~----~--------~--------- { 
|tElement subparameter must not be used | 


j2Not needed if file is cataloged | 


{ec 
ee 
Fig 


DCB 


DSO 


BUF 


ATLG, UNCATLG not permitted | 


DD Statement Parameters Applic- 
able to QISAM and BISAM Input 
and I-O Files 


ure 18. 


This parameter must be specified for 
each DD statement and is coded as 
follows: 


DCB= (DSORG=IS 
{, BUFNO=integer] 
{, OPTCD=([LI LY] [I] [R) (wW] 
(M,NTM=integer]] 
{, BLKSIZE=integer] ) 


RG=IS 
The 
and 


DSORG=IS subparameter is required 
indicates that the organization of 
the file is indexed sequential. The 
DCB subparameters of all the DD state- 
ments defining one file must not con- 
flict. For example, if the OPTCD=Y 
subparameter appears in the first DD 
statement, the subsequent DD state- 
ments should also contain OPTCD=Y. 

The subparameters are discussed below. 


NO=number of buffers 
This subparameter is used to specify 
the number of buffers to be assigned 
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to the file if no RESERVE clause is 
specified for the file in the source 
program. The maximum number is 255; 
however, the maximum number allowed 
for an installation may differ and is 
established at system generation time. 


OPTCD=options 
This subparameter is used to tell the 
system that certain additional facili- 
ties are to be provided for this file. 
Any combination of the following 
options can be specified for the OPTCD 
subparameter. If more than one option 
is specified, the options are written 
as a character string (i-e., without 
intervening blanks or commas). Note 
that if certain of these options are 
used, an additional subparameter must 
also be specified as indicated. The 
following options are unconditionally 
provided: 


1. The operating system supplies 
OPTCD=L and I. 


2. The operating system supplies 
OPTCD=W for the IBM 2321 direct- 
access device. 


e OPTCD=L: This option requests that 
the control program delete marked 
records. Marked records will be 
deleted when space for new records 
is required. 


e OPTCD=Y: This option requests that 
a cylinder overflow area be created. 
It specifies that a certain number 
of tracks on each cylinder are to be 
reserved to contain any overflow 
records from other tracks on that 
cylinder. Another DCB subparameter, 
CYLOFL=xx, must also be written. xx 
specifies the number of tracks on 
the cylinder to be reserved for the 
overflow area. The maximum number 
is 99. 


e OPTCD=I: This option requests that 
an independent overflow area be re- 
served. It is used in conjunction 
with DSNAME=dsname (OVFLOW) para- 
meter in the DD statement used to 
allocate the independent area. 


e OPTCD=M: This option requests that 
a master index be created (see 
“Additional Facilities" in this sec- 
tion for a discussion of master 
indexes). Another DCB subparameter, 
NITM=xx, must also be written. It 
specifies the maximum number of 
tracks to be contained in the 
cylinder index before a higher level 
index is created. The maximum value 
that can be specified is 99. 
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e OPTCD=R: This option requests reor- 
ganization criteria feedback, as 
described in “Reorganizing an Inde- 
xed Sequential File" in this 
section. 


e OPTCD=W: This option requests the 
system to perform a write-validity 
check. This facility is described 
under "Processing with QSAM." 


The following is an example of how the 
OPTCD subparameter can be used: 


DCB= (DSORG=IS, OPTCD=M, NTM=20) 


This example requests that a master 
index be created when the cylinder 
index exceeds 20 tracks. 


BLKSI ZE=integer 
specifies the blocksize. This clause 
is used only if BLOCK CONTAINS 0 
RECORDS was specified at compile time. 


PS A NS ET EE ES LS SS SE OT NS EO ES LY EE SE A eS SP 


Files: The following examples all refer to 
files that can be contained on one volume. 
More details about DD statements, including 
information on multi-volume file alloca- 
tion, can be found in the publication IBM 
System/360_ Operating System: Job Control 


Lanquage, Form C28-6539. 


All three areas for an indexed sequen- 
tial file can be contained on a single 
volume if they are small enough. If this 
is the case and the programmer elects to 
allow the system to subdivide storage into 
the prime and index areas when the file is 
created, he need only code the following DD 
statement: 


//dadname DD DSNAME=dsname (PRIME), X 
// SPACE=(CYL, (no. of x 
// cylinders)),UNIT=unit, X 
// DCB= (DSORG=IS, «ee ) 


This DD statement will produce a prime area 
with the index area occupying the last 
cylinder(s) of the space in the prime area. 
If any tracks are left over on the last 
cylinder after the index area, they are 
used as the overflow area; if no tracks are 
left over, an overflow area does not exist. 


If the programmer definitely wants an 
independent overflow area, he must provide 


//ddname DD DSNAME=dsname(PRIME), xX 
‘7 SPACE=(CYL, (no. of x 
47 cylinders)),UNIT=unit, X 
J/ VOLUME=SER=222222, X 
// DCB=(DSORG=IS,.-..) 

// DD DSNAME=dsname(OVFLOW), X 
1/7 SPACE=(CYL, (no. of x 
// cylinders)),UNIT=unit, X 
17 VOLUME=SER=222222, X 
1/ DCB=(DSORG=IS,...) 


These DD statements will produce a prime 

area and a separate overflow area with the 
index area at the end of the overflow area. 
All three areas reside on the same volume. 


Note: When more than one DD statement is 
used, only the first can be named. The 
others must not have a data definition name 
(ddname) but all must have the same data 
set name (dsname). 





If the programmer desires more control 
in the placement of the index area, he can 
subdivide storage before the data set is 
created by providing another DD statement 
as follows: 


//dadname DD DSNAME=dsname (INDEX), X 
Th SPACE=(CYL, (no. of X 
// cylinders)),UNIT=unit, X 
Jf VOLUME=SER=333333, xX 
1/ DCB=(DSORG=IS, ee.) 

J/ DD DSNAME=dsname(PRIME), Xx 
Jf SPACE=(CYL, (no. of xX 
// cylinders)),UNIT=unit, X 
// VOLUME=SER= 333333, x 
11 DCB=(DSORG=IS, ee) 


These DD statements will produce two separ- 
ate areas: index and prime. Each area is 
on the same volume. 


If, along with more control of his 
index, the programmer wishes an independent 
overflow area, he can specify a third DD 
statement as described above. The order 
will then be: 


//adname DD 
// DD 
// DD 


DSNAME=dsname (INDEX), ...- 
DSNAME=dsname (PRIME), «ee. 
DSNAME=dsname (OVFLOW),... 


These DD statements will produce three 
separate areas: index, prime, and 
overflow. 


Note that the OPTCD subparameter of the 
DCB parameter in each of the DD statements 
must specify an independent overflow area 
(OPTCD=I). All three areas reside on the 
same volume if so specified in the VOLUME 
parameter. 


Note: The order of the DSNAME parameter 
elements in all of the examples above must 
be followed when placing the DD statements 
‘into the input stream, or an abnormal ter- 
mination of the job will result. 


The example in Figure 19 defines a new 
indexed sequential file that consists of 
three separate areas. All three areas 
reside on the same volume. The volume is 
on an IBM 2311 Disk Storage Drive. 


Cataloging Files: An indexed sequential 
file can be cataloged if: 


e All the areas of the file are allocated 
with a single DD statement. Such a 
file is cataloged in the usual manner 
by specifying the DISP parameter in the 
DD statement: 


DISP= (NEW, CATLG) 


e The areas are allocated with more than 
one DD statement, but all volumes are 
on the same type of device. Sucha 
file is cataloged using the IEHPROGM 
utility program (see the publication 


Utilities, Form C28-6586). 


An indexed sequential file that is being 
created cannot be cataloged if its areas 
are on different device types. An existing 
indexed sequential file cannot be cataloged 
through the specification of the CATLG sub- 
parameter of the DISP parameter in the DD 
statement. 


Note: The DD statement or statements 
defining a new or existing indexed sequen- 
tial file can appear in cataloged 
procedures. 


aa a a aa a a a ada ala 1 
| //¥FILE DD DSNAME=ISMCINDEX), UNIT=2311,SPACE=(CYL,(1)), xX | 
| VOLUME=SER=111111, DCB=(DSORG=IS, ««.) | 
] DD DSNAME=ISM(PRIME), UNIT=2311,SPACE=(CYL,(5)), xX | 
| “/ VOLUME=SER=111111, DCB=(DSORG=IS, .--) | 
| S/ DD DSNAME=ISM(OVFLOW) , UNIT=2311,SPACE=(CYL, (1)), X | 
| 4 VOLUME=SER=111111, DCB=(DSORG=IS,...) | 
Pete etuiel So Soe See eo ee ea ee ee ee ee eee J 
Figure 19. Example of DD Statements for New Indexed Sequential Files 
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Calculating Space Requirements: To deter- 
mine the number of cylinders required for 
an indexed sequential file, the programmer 
must consider the number of records that 
will fit on a cylinder, the number of 
records that will be processed, and the 
amount of space required for indexes and 
overflow areas. In making the computa- 
tions, additional space is also required 
for device overhead. Detailed information 
can be found in the publication IBM System’ 
360 Operating System: __Supervisor_and Data 
Form C28-6646. 


Additional Facilities; The Master Index: 
QISAM provides a master index facility to 


avoid inefficient serial searches of large 
cylinder indexes. The master index pro- 
vides an index to the cylinder index. The 
programmer can specify with the DCB 
parameter in his DD statement(s) (see 
"“QISAM DD Statement Requirements" above) 
that a master index be built if the size of 
a cylinder index exceeds a certain number 
of tracks. Each entry in the master index 
points to a track of the cylinder index. 

If the size of the master index exceeds the 
number of tracks specified in the NTM para- 
meter of the DD statement, the master index 
is automatically indexed by a higher level 
master index. Three such higher level 
master indexes can be constructed. 


COBOL Considerations: When creating 
indexed sequential files, the QISAM file 
processing technique is used. The follow- 
ing COBOL programming considerations should 
be noted: 


¢ RECORD KEY Clause. The RECORD KEY 
clause in the SELECT sentence of the 
Environment Division is required. It 
is used to specify the location of the 
key within the record itself. If the 
RECORD KEY clause has a PICTURE clause 
that specifies that the item is binary 
(COMPUTATIONAL), zero is the lowest 
number acceptable as the first record. 
A negative key is considered to be 
larger than a positive key; therefore, 
if a record is inserted into the file, 
a negative key would place the record 
after those records with positive keys. 


e Dummy Records. To reserve space for 
records to be added at a later time, 
when creating indexed sequential files, 
dummy records can be written with the 
delete code (the figurative constant 
HIGH-VALUE) in the first byte. Dummy 
records and deletion are described 
later in this section. 


te rr i a a wr a i ae ae a ea ae ae a ee 


ED SEQUENTIAL FILES The QISAM file 
processing technique can be used to read or 
update an existing indexed sequential file. 
Adding a record to an already existing 
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file, however, can only be done with BISAM 
(see “Processing with BISAM" below). 


When the QISAM file processing technique 
is used to read an input file, the READ 
statement makes available one logical 
record at a time in an ascending order 
determined by the record keys. Dummy reco- 
rds are not made available. If there are 
records in the overflow area, this order 
will not correspond exactly to the physical 
order of the records in the file. The file 
must have been created using QISAM. 


When the QISAM file processing technique 
is used to update an I-O file, the READ and 
REWRITE statements permit updating-in-place 
or deletion of a logical record. A logical 
record is updated-in-place by reading, 
updating, and rewriting it from the same 
area. Alteration of record length or 
insertion of new records is not permitted. 
A logical record is marked for deletion by 
moving the figurative constant HIGH-VALUE 
into the first character position of the 
record and then using the REWRITE state- 
ment. Records in the file that contain 
this deletion code are not made available. 


The discussion that follows is primarily 
concerned with QISAM files that can be con- 
tained on a single volume. Additional 
information about processing existing QISAM 
files, including multi-volume files, can be 
found in the publication IBM System/360 


Operating System: Job Control Lanquage, 
Form C28-6539. 


rameter Requirements In the DD state- 
ment(s) indicating an existing indexed 
sequential file, the following differences 
and requirements should be noted: 


DCB 
The DSORG=IS subparameter must be 
specified, whereas the BUFNO subpara- 
meter is optional. The OPTCD field 
must not be specified again. Any 
OPTCD subparameter facilities that 
were specified when the file was 
created are in effect as long as the 
data set exists. For example, if the 
programmer specified the write- 
validity check option (OPTCD=W) when 
he created the file, the option is 
still in effect at the time of any 
subsequent WRITE statement. The 
BLKSIZE subparameter must not be 
specified. 


DSNAME 
This parameter is written DSNAME= 


dsname. The element subparameters 
(INDEX, PRIME, OVFLOW), must not be 
written. 


DISP 
The first subparameter must be OLD. 
The second subparameter cannot be 
CATLG or UNCATLG (see "Cataloging 
Files" above for more information on 
cataloging indexed sequential files). 


For further information about QISAM parame- 
ters, see the section “QISAM DD Statement 
Requirements" above. 


Using _the_DD_ Statement _--_Single-Volume 
Files: Only one DD statement is needed to 


specify an existing file if all of the 
areas are on one volume. The following is 
an example of a DD statement that can be 
used when processing a single-volume QISAM 
file. 


//ddname DD DSNAME=dsname, DCB= X 
// (DSORG=IS, eee), X 
/f UNIT=unit name, DISP=OLD 


Further details about DD statements for 
existing single-volume and multi-volume 
QISAM files can be found in the publication 


IBM System/360 Operating System: Job Con- 
trol Language, Form C28-6539. 


Additional_Facilities; Reorganizing Files: 
As new records are added to an indexed 
sequential file, chains of records may be 
created in the overflow area, if one 
exists. The access time for retrieving 
records in an overflow area is greater than 
that required for retrieving records in the 
prime area. I-O performance is, therefore, 
sharply reduced when many overflow records 
develop. For this reason, an indexed 
sequential file can be reorganized as soon 
as the need becomes evident. The system 
maintains a set of statistics to assist the 
programmer when reorganization is desired. 
These statistics are maintained as fields 
of the file's data control block. The 
location of the data control block can be 
passed to a called assembler language pro- 
gram, which can then test its fields. If 
these statistics are desired, the OPTCD 
subparameter of the DCB parameter must have 
included OPTCD=R in each of the DD state- 
ments when the file was created. Addition- 
al information is contained in the publica- 
tion IBM System/360 Operating System: _ 
Supervisor and Data Management Services, 
Form C28-6646. 

SETL Macro Instruction: For QISAM input 
and I-O files, retrieval starts with the 
first non-dummy record in the file. If the 
programmer wishes to begin processing at a 
point other than the beginning of the file, 
he can do so through the use of the SETL 
macro instruction; however, the programmer 
must set (with a logical OR) the MACRF 
field of the DCB for the file prior to the 
OPEN for the file. He can then specify the 


record key or device address at which 
retrieval is to start. 


The SETL macro instruction can be used 
more than once in the course of processing 
the file; however, an ESETL macro instruc- 
tion must be specified before the new SETL 
Macro instruction can be executed (see 
"Calling and Called Programs" for conven- 
tions used in calling assembler language 
programs). 


COBOL Considerations: When processing with 
QISAM, the following COBOL programming con- 
siderations should be noted: 


e RECORD KEY Clause. The RECORD KEY 
clause in the SELECT sentence of the 
Environment Division is required, just 
as it is when creating the file. Note 
other record key considerations under 
"Processing with BISAM." 


® Delete Option. In order to keep the 
number of records in the overflow area 
to a minimum, and to eliminate unneces- 
sary records, an existing record may be 
marked for deletion. This is done by 
moving the figurative constant HIGH- 
VALUE into the first character position 
of the record. The record is not phys- 
ically deleted unless it is forced off 
its prime track by the insertion of a 
new record, or if the file is reor- 
ganized (see “Additional Facilities" 
above). The deleted record may be 
replaced (using BISAM) by a record with 
an equal key without an error being 
indicated. Execution of the READ 
statement in QISAM does not produce a 
record marked for deletion, whether the 
record has been physically deleted or 
not. Dummy records and deletion are 
discussed further in "Processing with 
BISAM. " 


e If, in the same COBOL program, the 
programmer desires to create an indexed 
sequential file, close it, and then 
open it as an input or I-O file, he 
must specify another file name. The 
same DD statement(s) may not be used. 


e A separate set of DD statements is 
required for each of the following 
operations on the same file: 

1. Creating a QISAM file 


2. Opening it as a QISAM I-O or input 
file 


3. Opening it as a BISAM file 
The same file name is used each time in 


the DSNAME parameter. 
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PROCESSING WITH BISAM; READING, WRITING, 
AND REWRITING INDEXED SEQUENTIAL FILES: 


The BISAM file processing technique can be 
used for the direct retrieval of any log- 
ical record by its key, the direct update- 
in-place of any logical record, and the 
direct insertion of new logical records 
into an indexed sequential file. Only 
files created by the use of QISAM can be 
referred to by BISAM. 


Because of their complementary use of 
the indexed sequential file organization, 
much of the data given for QISAM in 
"Processing with QISAM" applies to BISAM. 
Differences will be noted below. 


BISAM K Both symbolic keys and record 
keys are required when using BISAM. The 
symbolic key is the field named in the SYM- 
BOLIC KEY clause of the File-Control para- 
graph of the Environment Division. When a 
record is read or written using BISAM, it 
is located by matching the contents of its 
RECORD KEY field with the contents of the 
field named in the SYMBOLIC KEY clause. 


Since a record key is used to identify a 
record to the system, the record keys asso- 
ciated with the logical records of the file 
may be thought of as a table of arguments. 
The symbolic key may be considered to be a 
search argument that is compared with 
entries in the table. When a new record is 
added to an existing file, the contents of 
the field named in the SYMBOLIC KEY clause 
are used to locate the two records in the 
file between which the new record is to be 
inserted. The records sought are those 
having respective RECORD KEY field contents 
less than and greater than the value in the 
SYMBOLIC KEY field. 


Using WRITE: The programmer can use the 
WRITE statement to cause the insertion of a 
new record into an indexed sequentail file. 
The insertion is done on the basis of the 
value specified in the symbolic key. Two 
methods can be used to add records. 


In the first method, the key to be added 
is a new key value. The record is inserted 
in place so that the order of the keys is 
maintained. If an overflow area exists, 
the insertion may cause records to be 
forced off the prime area track into the 
overflow area. Dummy records forced off 
the track in this way are physically 
deleted and are not written in the overflow 
area. 


In the second method, the key of the 
record to be added has the same value as 
that of a known dummy record. If the dummy 
record has not been physically deleted, it 
is replaced by the new record. If it has 
been physically deleted, the record is 
inserted as if it had a new key value. 


66 


Records with a key higher (or lower) 
then the current highest (or lowest) key of 
the file may be added. When a record is 
added, both the record key and symbolic key 
must have the same value. Except in the 
case of dummy records, this value must be 
unique in the file. 


REWRITE If the REWRITE statement is 
being used to update a record in place, the 
programmer cannot change the size of a 
record between the time it is read and the 
time it is rewritten. When a BISAM file is 
opened as I-O and a REWRITE statement for 
the file-name is issued anywhere in the 
program, a REWRITE statement must be given 
after every READ statement and previous to 
any Other input/output statement for the 
same file-name. However, a REWRITE state- 
ment should not be given if an invalid READ 
condition occurs. 


If the programmer wishes to write a new 
record (RECORDY) before updating and re- 
writing the contents of a record he has 
previously read (RECORDX), he might use the 
following sequence of instructions: 


READ statement -- to obtain RECORDX 


REWRITE statement -- for RECORDX 
WRITE statement -- for RECORDY 
READ statement -- for RECORDX 


Update contents of RECORDX 


REWRITE statement -- for RECORDX 
Using READ: Records are retrieved on the 


basis of the value specified in the symbol- 
ic key. If the key of a record marked for 
deletion is specified and the record has 
not been physically deleted, it will be 
produced. If the record has been physical- 
ly deleted, the READ statement will cause 
an invalid key condition and control will 
go to the invalid key routine, if 
specified. 


BOL Considerations When processing with 
BISAM, the following COBOL programming con- 
siderations should be noted: 


e RECORD KEY and SYMBOLIC KEY Clauses. 
The RECORD KEY and SYMBOLIC KEY clauses 
in the SELECT sentence of the Environ- 
ment Division are required. The RECORD 
KEY clause is used to specify the loca- 
tion of the key within the record 
itself. The symbolic key is used as a 
search argument to locate the proper 
record, and must not be defined within 


the file being processed. Note that 
since a record key is defined within a 
record, the contents of RECORD KEY are 
not available after a WRITE statement 
has been executed for that record. 


e TRACK-AREA Clause. Specifying the 
clause results in a considerable 
improvement in efficiency when a record 
is added. If a record is added and the 
TRACK-AREA clause was not specified for 
the file, the contents of the SYMBOLIC 
KEY field are unpredictable after the 
WRITE statement is executed. In this 
case, the key must be reinitialized 
before the next WRITE statement is 
executed. 
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USING THE DD STATEMENT 


Each data set that is defined by a DD statement is either (1) to be 
created, or (2) has been previously created and is to be retrieved. In 
either case, the data set must have a disposition; for example, if the 
data set is being created, the disposition must indicate whether the 
data set is to be cataloged, kept, or deleted. Other DD statements may 
simply indicate that the data set is in the input stream or that 
ultimately the data set is to be printed or punched. 


The following sections summarize the DD statement parameters and show 
examples for various uses of the DD statement. These sections include 
information about cataloging data sets and creating or referring to 
generation data groups; examples of cataloged data sets and partitioned 
data sets are included. For additional information about partitioned 
data sets refer to the chapter "Libraries." See “A Checklist for Job 
Control Procedures" for additional examples of the DD statement used in 
job control procedures. 


CREATING A DATA SET 


The programmer will ordinarily be concerned with the following param- 
eters when he is creating a data set: 


1. The data set name (DSNAME) parameter, which assigns a name to the 
data set being created. 


2. The unit (UNIT) parameter, which allows the programmer to state the 
type and quantity of input/output devices to be allocated for the 
data set. 


3. The volume (VOLUME) parameter, which allows specification of the 
volume in which the data set is to reside. This parameter also 
gives instructions to the system about volume mounting. 


4. The space (SPACE), split cylinder (SPLIT), and suballocation (SUB- 
ALLOC) parameters, for direct-access devices only, which permit the 
specification of the type and amount of space required to accom- 
modate the data set. 


5. The label (LABEL) parameter, which specifies the type and some of 
the contents of the label associated with the data set. 


6. The disposition (DISP) parameter, which indicates what is to be 
done with the data set by the system when the job step is 
completed. 


7. ‘(The DCB parameter, which allows the programmer to specify addition- 
al information to complete the DCB associated with the data set 
(see "User Defined Files"). This allows additional information to 
be specified at execution time to complete the DCB constructed by 
the compiler for a data set defined in the source program. 


Figure 20 shows the subparameters that are frequently used in creat- 
ing data sets. Additional subparameters are discussed in "Format of the 
Job Control Statements." 
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Figure 20. Parameters Frequently Used in Creating Data Sets 


Examples of DD Statements Used to Create Data Sets 


ters and subparameters that are specified depend on the disposition of 


the data set at the end of the job step. 
the job step in which it is created and is deleted at the end of this 


The following examples show various ways of specifying DD statements 
for data sets that are to be created. In general, the number of parame- 


If a data set is used only in 


job step, a minimum number of parameters are required. However, if the 
data set is to be cataloged, more parameters should be specified. 


Example 1: Creating a data set for the current job step only. 


//SYSUT1 DD UNIT=SYSDA, SPACE=(TRK, (50,10)) 


data set and storing it on a direct-access device. 
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This example shows the basic required DD statement for creating a 


The UNIT parameter 


is required unless the unit information is available from another 
source. If the data set were to be stored on a unit record or a tape 
device, the SPACE parameter would not be needed. The operating system 
assigns a temporary data set name and assumes a disposition of (NEW, 
DELETE). 


Example 2: Creating a data set that is used only for the current job. 


//SYSLIN DD DSNAME=&TEMP, DISP=(MOD, PASS), UNIT=SYSSQ, X 
4/ SPACE=(TRK, (50) ) 


This example shows a DD statement that creates a data set for use in 
more than one step of a job. The system assigns a unique symbol for the 
name, and this same symbol is substituted for each recurrence of the 
&TEMP name within the job. The data set is allocated space on any 
available direct-access or tape device. If a tape device is selected, 
the SPACE parameter is ignored. The disposition specifies that the data 
set is either new or is to be added to (MOD), and is to be passed to the 
next job step (PASS). This DD statement can be used for specifying the 
data set that is created as output from the compiler and is to be used 
as input to the linkage editor. By specifying MOD, separately compiled 
object modules can be placed in sequential order in the same volume. 


Note: If MOD is specified for a data set that does not already exist, 
the job may be abnormally terminated if a volume reference name, a 
volume serial number, or the disposition CATLG is specified, or if the 
dsname is indicated by a backward reference. 


Example 3: Creating a data set that is to be kept but not cataloged. 


//TEMPFILE DD DSNAME=FILEA, DISP=(, KEEP), SPACE=(TRK, (30,10)), x 
4/ UNIT=DIRECT, VOLUME=(, RETAIN, SER=AA70) 


The example shows a DD statement that creates a data set that is kept 
but not cataloged. The data set name is FILEA. The disposition (, KEEP) 
specifies that the data set is being created in this job step and is to 
be kept. It is kept until a disposition of DELETE is specified on 
another DD statement. KEEP implies that the volume is to be treated as 
private. Private implies that the volume is unloaded at the end of the 
job step but because RETAIN is specified, the volume is to remain 
mounted until the end of the job unless another reference to it is 
encountered. DIRECT is a hypothetical device class, containing only 
direct-access devices. The volume with volume serial number AA70O, 
mounted on a device in this class, is assigned to the data set. Space 
for the data set is allocated as specified in the SPACE parameter. The 
data set has standard labels since it is in a direct-access volume. 


If the volume serial number were not specified in the above example, 
the system would allocate space in an available non-private volume. 
Because KEEP is specified, the volume becomes private. (Another data 
set cannot be stored on a private volume unless its volume serial number 
is specified or affinity with a data set on the volume is stated.) The 
volume serial number of the volume assigned, if applicable, is included 
in the disposition message for the data set. Disposition messages are 
messages from the job scheduler, generated at the end of the job step. 


Example 4: Creating a data set and cataloging it. 


//DDNAMEA DD DSNAME=INVENT. PARTS, DISP=(NEW, CATLG), X 
11 LABEL=(, , EXPDT=67031) , UNIT=DACLASS, X 
// VOLUME=(, REF=*.STEP1.DD1), X 
11 SPACE=(CYL, (5,1),, CONTIG) 


This example shows a DD statement that creates a data set named 
INVENT.PARTS and catalogs it in the previously created system catalog. 
The data set is to occupy the same volume as the data set referred to in 
the DD statement named DD1 occurring in the job step named STEP1. The 
UNIT parameter is ignored since REF is specified. Five cylinders are 
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allocated to the data set, and if this space is exhausted, more space is 
allocated, one cylinder at a time. The five cylinders are to be contig- 
uous. The disposition (CATLG), implies that the volume is to be 
private. The INVENT.PARTS is to have standard labels. The expiration 
date is the 31st day of 1967. 


Example 5: Adding a member to a previously created library. 


7/SYSLMOD DD DSNAME=SYS1.LINKLIB(INVENT) , DISP=OLD 


This DD statement adds a member named INVENT to the link library 
(SYS1.LINKLIB). When a member is added to a previously created data 
set, MOD should be specified. The member INVENT takes on the disposi- 
tion of the library. 


Example 6: Creating a library and its first member. 


//SYSLMOD DD DSNAME=USERLIB(MYPROG) , DISP=(,CATLG), X 
41 SPACE=(TRK, (50, 30, 3)) , UNIT=2311, VOLUME=SER=111111 


This DD statement creates a library, USERLIB, and places a member, 
MYPROG, in it. The disposition (,CATLG) indicates that the data set is 
being created in this job step (NEW is the default condition for the 
DISP parameter and is indicated by the comma) and is to be cataloged. 
The data set is to have standard labels. Space is allocated for the 
data set in a volume on a direct-access device which belongs to the 
device class 2311. Initially, 50 tracks are allocated to the data set, 
but if this space is exhausted, more tracks are added 30 at a time. The 
SPACE parameter must be specified when the library is created, and it 
must include allocation of space for the directory. SPACE cannot be 
specified when new members are added. If additional space is required 
when new members are added, the secondary allocation, if specified, will 
be used. Three 256-byte records are to be used for the directory. The 
volume serial number of the volume in which the library is to reside, is 
111111. 


Example 7: Replacing a member of an existing library. 
//SY¥SLMOD DD DSNAME=MYLIB(CASE3) , DISP=OLD 


This DD statement replaces the member named CASE3 with a new member 
with the same name. If the named member does not exist in the library, 
the member is added as a new member. In the above example, the library 
is cataloged. 


Example 8: Creating and adding a member to a library used only for the 
current job. 


//SYSLMOD DD DSNAME=&USERLIB (MYPROG) , DISP=(, PASS) , UNIT=SYSDA, Xx 


This DD statement creates and adds a member to a temporary library. 
It is similar to the DD statement shown in Example 6, except that a tem- 
porary name is used and the data set is not cataloged nor kept but is © 
simply passed to the next job step. Since the data set is to be used 
only for this one job, it is not necessary to specify VOLUME and LABEL 
information. This statement can be used for a linkage editor job step 
in which the module is to be passed to the next step. 


Note: If DISP=, (DELETE) is specified for a library, the entire library 
will be deleted. 
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RETRIEVING PREVIOUSLY CREATED DATA SETS 


The parameters that must be specified in a DD statement to retrieve a 
previously created data set depend on the information that is available 
to the system about the data set. For example, 


1. If a data set in a magnetic-tape or direct-access volume was 
created and cataloged in a previous job or job step, all informa- 
tion for the data set, such as volume, space, etc., is stored in 
the catalog and data set label. This information need not be 
repeated. Only the dsname and disposition parameters need be 
specified. 


2. If the data set was created and kept in a previous job but has not 
been cataloged, information concerning the data set, such as space, 
record format, etc., is stored in the data set label. However, the 
unit and volume information must be specified unless otherwise 
available. 


3. If the data set was created in the current job step, or in a pre- 
vious job step in the current job, the information in the previous 
DD statement is available to the system and is accessible by refer- 
ring to the previous DD statement. Only the dsname and disposition 
parameters need be specified. 


Note: A programmer may wish to change the previous disposition of a 
data set. For example, if KEEP was specified when the data set was 
created, the DD statement that retrieves the data set may change the 
disposition by specifying CATLG. 


Figure 21 shows the subparameters that are used to retrieve previous- 
ly created data sets. 
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Figure 21. Parameters Frequently Used in Retrieving Previously Created 
Data Sets 


Example 1: Retrieving a cataloged data set. 


//CALC DD DSNAME=PROCESS, DISP= (OLD, PASS) 
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This DD statement retrieves a cataloged data set named PROCESS. No 
UNIT or VOLUME information is needed. Since PASS is specified, the 
volume in which the data set is written is retained at the end of the 
job step. PASS implies that a later job step will refer to the data 
set. The last step in the job referring to the data set should specify 
the final disposition. If no other DD statement refers to the data set, 
the status of the data set as it existed before this job is assumed. 


Example 2: Retrieving a data set that was kept but not cataloged. 


//TEMPFILE DD DSNAME=FILEA, UNIT=DIRECT, VOLUME=SER=AA70, DISP=OLD 


This DD statement retrieves a kept data set named FILEA. (This data 
set is created by the DD statement shown in EXAMPLE 3 in creating data 
sets.) The data set resides on a device in a hypothetical device class, 
DIRECT. The volume serial number is AA70O. 


Example 3: Referring to a data set in a previous job step. 


// SAMPLE JOB 
//STEP1 EXEC PGM=IEQCBLO0, PARM=DECK 


//SYSLIN DD DSNAME=ALPHA, DISP=(NEW, PASS) , UNIT=SYSSQ 
//STEP2 EXEC PGM=IEWL 
//SYSULIN DD *. STEP1. SYSLIN, DISP= (OLD, DELETE) 


The DD statement SYSLIN in STEP2 refers to the data set defined in 
the DD statement SYSLIN in STEP1. 


Example 4: Retrieving a member of a library. 
//BANKING DD DSNAME=PAYROLL (HOURLY) , DISP=OLD 


The DD statement retrieves a member, HOURLY, from a cataloged 
library, PAYROLL. 


DD STATEMENTS THAT SPECIFY UNIT RECORD DEVICES 


A DD statement may simply indicate that data follows in the input 
stream or that the data set is to be punched or printed. Figure 22 
shows the parameters of special interest for these purposes. 


DABAY 


SYSOUT=A 
UNIT=name 


| 
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| 
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| 
DCB=(subparameters); Note: The DCB parameter can be specified, | 
where permissible, for data sets on unit reco-| 

rd devices. For example, it can be specified | 

for compiler data sets (other than SYSUT1, | 

SYSUT2, SYSUT3, and SYSUT4) and data sets spe-| 

cified by the DD statements required for the | 

ACCEPT and DISPLAY statements, when any of | 

these data sets are assigned to unit-record | 

devices. | 
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Figure 22. Parameters Used to Specify Unit Record Devices 
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Example 1: Specifying data in the card reader. 
//SYSIN DD * 


The asterisk indicates that data follows in the input stream. This 
statement must be the last DD statement for the job step. The data must 
be followed by a delimiter statement. 


Example 2: Specifying a printer data set. 
//SYSPRINT DD SYSOUT=A 


SYSOUT is the system output parameter; A is the standard device class 
for printer data sets. 


Example 3: Specifying a card punch. 
//SYSPUNCH DD SYSOUT=B 


B is the standard device class for punch devices. 


CATALOGING A DATA SET 


A data set is cataloged whenever CATLG is specified in the DISP 
parameter of the DD statement that creates or uses it. This means that 
the name and volume identification for the data set are placed in a sys- 
tem index called the catalog. (See "Processing with QISAM" in the sec- 
tion "Execution Time Data Set Requirements" for information about cata- 
loging indexed sequential data sets.) The information stored in the 
catalog is always available to the system; consequently, only the data 
set name and disposition need be specified in subsequent DD statements 
that retrieve the data set. See Example 4 in "Creating Data Sets," and 
Example 1 in "Retrieving Data Sets." 


If DELETE is specified for a cataloged data set, any reference to the 
data set in the catalog is deleted unless the DD statement containing 
DELETE retrieves the data set in some way other than by using the cata- 
log. If UNCATLG is specified for a cataloged data set, only the 
reference in the catalog is deleted; the data set itself is not deleted. 


Note: A cataloged data_set should not be confused with a cataloged pro- 
cedure (see "Cataloged Procedures"). 





GENERATION DATA_GROUPS 


It is sometimes convenient to save data sets as elements or genera- 
tions of a generation data group (DSNAME=dsname(element)). A generation 
data_group is a collection of successive historically related data sets. 
Identification of data sets that are elements of a generation data group 
is based upon the time the data set is added as an element. That is, a 
generation number is attached to the generation data group name to refer 
to a particular element. The name of each element is the same, but the 
generation number changes as elements are added or deleted. The most 
recent element is 0, the element added previous to 0 is -1, the element 
added previous to -1 is -2, etc. A generation data group must always be 
cataloged. 
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For example, a data group named PAYROLL might be used for a weekly 
payroll. The elements of the group are: 


PAYROLL (0) 
PAYROLL (-1) 
PAYROLL (-2) 


where PAYROLL(0) is the data set that contains the information for the 
most current weekly payroll and is the most recent addition to the 
group. 


When a new element is added, it is called element(+n), where n is an 
integer greater than 0. For example, when adding a new element to the 
weekly payroll, the DD statement defines the data set to be added as 
PAYROLL(+1); at the end of the job the system changes its name to 
PAYROLL(0). The element that was PAYROLL(0) at the beginning of the job 
becomes PAYROLL(-1) at the end of the job, and so on. 


If more than one element is being added in the same job, the first is 
given the number (+1), the next (+2) and so on. 


NAMING DATA SETS 


Each data set must be given a name. The name can consist of alpha- 
numeric characters and the special characters hyphen and plus 0 (12-0 
multipunch). The first character must be alphabetic. The name can be 
assigned by the system, it can be given a temporary name, or it can be 
given a user-assigned name. If no name is specified on the DD statement 
that creates the data set, the system assigns the data set a unique name 
for the job step. If a data set is used only for the duration of one 
job, it can be given a temporary name (DSNAME=éname). If a data set is 
to be kept but not cataloged, it can be given a simple name. If the 
data set is to be cataloged it should be given a fully qualified data 
set name. The fully qualified data set name is a series of one or more 
Simple names joined together so that each represents a level of qualifi- 
cation. For example, the data set name DEPT999. SMITH. DATA3 is composed 
of three simple names that are separated by periods to indicate a 
hierarchy of names. Starting from the left, each simple name indicates 
an index or directory within which the next simple name is a unique 
entry. The rightmost name identifies the actual location of the data 
set. 


Each simple name consists of one to eight characters, the first of 
which must be alphabetic. The special character period (.) separates 
Simple names from each other. Including all simple names and periods, 
the length of a data set name must not exceed 44 characters. Thus, a 
maximum of 21 qualification levels is possible for a data set name. 


Programmers should not use fully qualified data set names which begin 
with the letters SYS and which also have a P as the 19th character of 
the name. Under certain conditions, data sets with the above charac- 
teristics will be deleted. 
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This checklist illustrates general job 
control procedures for compiler, linkage 
editor, and execution processing. More 
than one example may be used for a job 
step. The checklist is intended as an aid 
in preparing procedures, not as an inclu- 
sive list of the options and parameters. 


COMPILATION 


Figure 23 shows a general job control 
procedure for a compilation job step. The 
following cases show how to add to or modi- 
fy the general procedure to obtain various 
processing options. 


Case 1: Compile Only - No Object Module 


Produced 


Use the general procedure. A listing is 
produced. It will include the default or 
specified options of the PARM parameter 
that affect output. Any diagnostic mes- 
Sages are listed, unless listing of warning 
messages is suppressed by the FLAGE option 
of the PARM parameter and only warning mes- 
sages are produced. 


|/7/jobname JOB acctno, name, MSGLEVEL=1 

ree EXEC PGM=IEQCBLOO, PARM=(options) 
en DD 
eee DD UNIT=SYSDA, (SPACE=subparms) 
i i7eieons DD UNIT=SYSDA, (SPACE=subparms) 
Seen DD UNIT=SYSDA, (SPACE=subparms) 
| eon DD SYSOUT=A 


| 
| //SYSIN DD 


Figure 23. 


UNIT=SYSDA, [SPACE=(subparms) ] 


DSNAME=dsname, UNIT=SYSSQ, VOLUME=(subparms) , DISP=(OLD, DELETE) 
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General Job Control Procedure for Compilation 
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Case 2: Source Module from Card Reader 


Modify the end of the procedure as 
follows: 


//SYSIN DD #* 
(source module) 
/* 


If the DD * convention is used, the 
SYSIN DD statement must be the last DD sta- 
tement for the job step, and the source 
module must follow. If another job step 
follows the compilation, the EXEC statement 
for that step follows the /* statement. 


Add the statement: 


J7/SYSPUNCH DD SYSOUT=B 


Note: If DECK is not the installation 
default condition, it must be specified in 
the PARM parameter of the EXEC statement. 
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Case 4: Object Module is to be Passed_to 


— ee ee 


Add the statement: 
4/SYSLIN DD DSNAME=(subparms), 
UNIT=SYSDA, 
SPACE=(subparms), 
DISP=(MOD, PASS) 


Note: If LOAD is not the installation 
default condition, it must be specified in 
the PARM parameter of the EXEC statement. 


Case 5:3 


The object module can be saved by cata- 
loging it, by keeping it, or by adding it 
as a member of a library. Add the SYSLIN 
statement as follows: 

A. Cataloging 

//SYSLIN DD DSNAME=dsname, 

aac » CATLG) 
MOD - 

VOLUME=(subparms), 

LABEL=(subparms), 

esas tea 
SYSSQ 


SPLIT 


jeer 
SUBALLOC 


=(subparms) 


Be Keeping 


“//SYSLIN DD DSNAME=dsname, 
cae 1s cana 
MOD 
VOLUME=(subparms), 
LABEL=(subparms), 
sac ceo 
SYSSQ 


SPLIT 


{seer 
SUBALLOC 


=(subparms) 


C. Adding a member to an Existing Library 


4/SYSLIN DD DSNAME=dsname(member), X 
Jf DISP=OLD 
Case 6: COPY or INCLUDE Statements in 


COBOL Source Module or a BASIS Card in the 
Input Stream 


Add the SYSLIB DD card(s), as follows: 
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A. COPY 

//SYSLIB DD DSNAME=copylibname, DISP=OLD 
B. BASIS 

//SYSLIB DD DSNAME=basislibname, DISP=OLD 
C. Both BASIS and COPY 


//SYSLIB DD DSNAME=basislibname, DISP=OLD 
// DD DSNAME=copylibname, DISP=OLD 


(DD statements for additional copylibs may 
follow.) 


Note: If BASIS or COPY are not the instal- 
lation default options, they must be speci- 
fied on the PARM parameter. 


LINKAGE: EDITOR 


Figure 24 shows a general job control 
procedure for a linkage editor job step. 
The following cases show how to add to or 
modify the procedure to obtain various 
processing options. 


Case 1: Input from Previous Compilation in 
Same Job 


Change the SYSLIN statement to 


//SXSLIN DD DSNAME=*.stepname.SYSLIN, xX 
1/1 DISP=(OLD, DELETE) 


where stepname is the name of the previous 
compilation job step and ddname is SYSLIN. 
If the input is to be saved, specify KEEP 
rather than DELETE. 


Case 2: Input from Card Reader 


Change the SYSLIN statement and the end 
of the procedure as follows: 


7/SYSLIN DD #* 
(object module(s)) 
J* 


If the DD * convention is used, the SYS- 
LIN DD statement must be the last DD state- 
ment in the job step. If another job step 
follows the linkage editor step, the EXEC 
statement for that job step follows the /* 
statement. 


7 
// jobname acctno, name, MSGLEVEL=1 


/stepname PGM=IEWL, PARM=(options) 


| 
| 
| 
| 
| 
| 
|//SYSPRINT DD SYSOUT=A 
| 

|//SYSLMOD DD 

| 
| //SYSLIB DD 
| 
|//SYSUT1 DD 
| 


/7/SYSLIN DD DSNAME=dsname, DISP=OLD 


Figure 24, 


Case 3: 
Job 


Input Not from Compilation in Same 


Specify in the SYSLIN DD statement where 
the object modules to be used as input are 
stored. (Only one member of a library can 
be specified in the SYSLIN DD statement.) 


Case 4: Output _ to be Placed in Link 
Library 


Change the SYSZLMOD statement as follows: 


//SXYSLMOD DD DSNAME=SYS1.LINKLIB(member) , X 
// DISP=OLD 


Member is the name of the load module that 
is to be added to the link library. No 
other information is needed in the 
statement. 


Case_5:_ Output to be Placed in Private 
Library 


Change the SYSLMOD statement as follows: 


//SXYSLMOD DD DSNAME=dsname (member), X 
J/ DISP=OLD 


Member is the name of the load module to be 
added, and dsname is the name of an exist- 
ing library. If the library is not cata- 
loged, UNIT and VOLUME parameters must be 
specified. 


Note: See "Using the DD Statement" for an 
example of creating a new library and stor- 
ing the load module as its first member. 


DSNAME= Sname (member) , UNIT=SYSDA, DISP= (NEW, PASS) , SPACE= (subparms) 
DSNAME=SYS1.COBLIB, DISP=OLD 
UNIT=SYSDA, SPACE=(subparms) 
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Case 6: Output to be Used Only in this Job 


Use the general procedure. The load 
module is stored in a temporary library. 


EXECUTION TIME 


ee ee ee ee ee ee ee oe 


Figure 25 shows a general job control 
procedure for an execution-time job step. 
The following cases show how to add to or 
modify the general procedure to obtain 
various processing options. 


Case 1: Load Module to be Executed is in 


Use the general procedure, where 
progname in the EXEC statement is the memb- 
er name of the load module. 


Case 2: Load Module to be Executed is a 


Member of Private Library 


The JOBLIB statement must follow the JOB 


statement, as in the following statements: 
7/IOB1 JOB = ------ 

“/TOBLIB DD DSNAME=MYLIB, Xx 
// DISP= (OLD, PASS) 

//STEP1 EXEC PGM=PAYROLL 

7/STEP2 EXEC PGM=ACCOUNT 
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//stepname EXEC PGM=progname 
|77ddname DD 


Figure 25. 


The JOBLIB statement defines the private 
library MYLIB. No volume or unit parame- 
ters are given since the library is cata- 
loged. Since JOBLIB has the disposition 
PASS, both steps can execute members of the 
library named in the JOBLIB statement. If 
only the first step executes a load module 
from the library, the disposition PASS on 
the JOBLIB statement need not be included. 


Load Module to be Executed is 


Fe ee SS eS EE EE ES ee eS 


Case 3: 


ee ae ee 


Change the EXEC statement as follows: 


//stepname EXEC PGM=*.stepname. SYSLMOD 


where the stepname following PGM is the 


name of the linkage editor job step that 
created the load module. 
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Add the statement: 
//SYSABEND DD SYSOUT=A 
This statement requests a full dump if 


abnormal termination occurs during 
execution. 


Case 5: DISPLAY is Included in Source 


Module 


Add the statement: 


//SYSOUT DD SYSOUT=A 
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(parameters for user-specified data sets) 
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General Job Control Procedure for an Execution-Time Job Step 


Case_6:__DISPLAY_UPON_SYSPUNCH_is_Included 
in Source Module 


Add the statement: 


//SYSPUNCH DD SYSOUT=B 


Case 7: ACCEPT is Included in Source 


If the data is in the input stream, add 
the statement: 


7/SYSIN DD * 
(data) 
/* 


(See Case 2 under "General Job Control Pro- 
cedures for a Compilation Job Step" for a 
discussion of the DD * convention. ) 


Use the statement (unless it is already 
included): 


//SYSOUT DD SYSOUT=A 
Note: If the job step already includes a 


SYSOUT DD statement for some other use, 
another need not be inserted. 


A cataloged procedure is a set of job 
control statements that has been placed in 
a partitioned data set called the procedure 
library (SYS1.PROCLIB). It can he re- 
trieved from the library by using its memb- 
er name in an EXEC statement of a job step 
in the input stream. Frequently used pro- 
cedures, such as those used for compiling 
and linkage editing, can be cataloged to 
simplify their subsequent use. 


A cataloged procedure can contain state- 
ments for the processing of an entire job, 
or it can contain statements to process one 
or more steps of a job, with the remaining 
steps defined by job control statements in 
the input stream. A ‘job can use several 
cataloged procedures, each processing one 
or more of the job steps. A job can also 
call for execution of the same cataloged 
procedure in more than one job step. 


This chapter describes the following: 
e How to call cataloged procedures 


e The types of cataloged procedures, 
including those supplied by IBM for use 
with COBOL (F) source programs 


e How to add procedures to the procedure 
library 


e How to modify existing procedures for 
the current job step only 


e How to override and add to cataloged 
procedures 


e How to use the DDNAME parameter in 
cataloged procedures 


CALLING CATALOGED PROCEDURES 


A cataloged procedure is called by a job 
that appears in the input stream. The job 
must consist of a JOB statement and an EXEC 
Statement that specifies the cataloged pro- 
cedure name in the positional parameter 
(either procname or PROC=procname). For 
example: 


//STEPQ EXEC COBFC 
4/STEPQ EXEC PROC=COBFC 


Either of these EXEC statements could be 
used to call the IBM-supplied cataloged 


CATALOGED PROCEDURES 


procedure COBFC to process the ‘job step 
STEPQ. 


A job step that calls for execution of a 
cataloged procedure can also contain DD 
statements that are applicable to the job 
steps of the cataloged procedure. A job 
that calls for execution of a cataloged 
procedure may, in other steps, call for 
execution of other cataloged procedures, 
call for other executions of the same cata- 
loged procedure, or call directly for 
execution of load modules. The following 
example shows a job control procedure that 
calls both cataloged procedures and load 
modules. 


S/S IJOBL JOB 

4/STEPA EXEC COBFC 

//COB. SYSIN DD * 
(source module) 

f* 

7//STEPL EXEC PGM=IEWL 


(DD statements for the linkage editor) 


EXEC 


4/STEPE PGM=*. STEPL. SYSLMOD 


(DD statements for user-defined files) 


The IBM-supplied cataloged procedure 
COBFC for compilation is used to process 
STEPA. The COB.SYSIN DD statement is re- 
quired to define the input to the compiler. 
The remaining statements in the procedure 
refer to execution of the linkage editor 
and the subsequent load module. 


Data_Sets_ Produced by Cataloged Procedures 


Data sets produced during execution of a 
cataloged procedure can he used in subse- 
quent job steps. They can also be called 
as follows: 
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//jobname JOB 1234,J9.SMITH 
//STEPA EXEC PROCED 
/#PROC1.SYSIN DD * 

(source module) 
/* 
//stepname EXEC PGM=*.STEPA. PROC2. SYSLMOD 
(DD statements for user-defined files) 


The cataloged procedure PROCED is com- 
posed of two job steps, PROC1 and PROC2, 
that compile and linkage edit the source 
module. 


TYPES OF CATALOGED PROCEDURES 


The programmer can write his own proce- 
dures and catalog them, or he can use the 
three COBOL cataloged procedures provided 
by IBM. 


PROGRAMMER-WRITTEN CATALOGED PROCEDURES 


The programmer can write cataloged pro- 
cedures, consisting of EXEC and DD state- 
ments, which incorporate ‘job control proce- 
dures he uses frequently. For example, the 
programmer may wish to catalog an EXEC 
statement and the associated DD statements 
for a job step that spécifies execution of 
a program. In this way the DD statements 
need not be specified each time the program 
is executed. 


In writing a procedure for cataloging, 
the programmer must follow these rules: 


e Another cataloged procedure cannot be 
referred to, i.e., only the PGM= 
progname form in an EXEC statement can 
be used. 


Note, however, that a cataloged proce- 
dure may contain a DD statement that 
refers to a cataloged data set. 


e The following statements cannot be used 
in a cataloged procedure: 


1. The JOB statement 


2. A DD statement with JOBLIB in the 
name field 


3. A DD statement with an * in the 
operand field 
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4. A DD statement with DATA in the 
operand field 


5. The delimiter statement 


Adding Procedures_to the Procedure Library 


The IEBUPDTE utility program is used to 
add procedures to the procedure library. A 
description of the use of this program is 


a ee ee 
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C28~-6586. 


In Figure 26, two procedures are added 
to the procedure library (SYS1.PROCLIB). 
All control statements are in the input 
stream. 


The first procedure is for a COBOL (F) 
compilation. Direct-access volumes are 
specified for the four utility data sets, 
and 100 tracks are allocated for each 
utility data set. This cataloged procedure 
is named COBDA. 


The second procedure is also for a COBOL 
(F) compilation. Unlabeled tape volumes 
are specified for the four utility data 
sets. This cataloged procedure is named 
COBTP. 


Job control statements: the EXEC card 
specifies that the IEBUPDTE program is to 
be executed, and the PARM=NEW is used 
because all data is read from one source, 
iee., the input stream. 


Utility statements: the ADD statement 
specifies the member name of the procedure, 
the level modification (00, first run) and 
the source of the modification (0, user- 
supplied). The NUMBER statement specifies 
the sequence numbers for records in the 
member. The first record of the cataloged 
procedure is numbered 00000010, and subse- 
quent records are incremented by 00000010. 


Note that leading zeros in the NUMBER 
statement are not necessary, as indicated 
in the example for the COBTP procedure. 


IBM-SUPPLIED CATALOGED PROCEDURES 


IBM distributes cataloged procedures 
with the operating system, which can be 
incorporated when the system is generated. 


a a aaa a te ee ek 
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Job 4/BADPROC JOB 1234, J7.DUBOB 

jCcontrol Yee EXEC PGM=IEBUPDTE, PARM=NEW 

| Language 4/SYSPRINT DD SYSOUT=A 

{Statements //SYSUT2 DD DSNAME=SYS1. PROCLIB, DISP=OLD 

| //SYSIN DD DATA 

| 

jUtility ee ADD NAME=COBDA, LEVEL=00, SOURCE=0 

| Statements of NUMBER NEW1=00000010, INCR=00000010 

| 

| /4/COB EXEC PGM=IEQCBL00 

| {//SYSUT1 DD UNIT=SYSDA, SPACE=(TRK, (100,10)) 
| 7/SYSUT2 DD UNIT=SYSDA, SPACE=(TRK, (100,10) ) 
| First //SYSUT3 DD UNIT=SYSDA, SPACE=(TRK, (100,10) ) 
| Procedure //SYSUTY DD UNIT=SYSDA, SPACE=(TRK, (100,10)) 
| 4/SYSPRINT DD SYSOUT=A 

| //SYSPUNCH DD SYSOUT=B 

ieeiies ee ADD NAME=COBTP, LEVEL=00, SOURCE=0 

| Statements o/ NUMBER NEW1=10, INCR=10 

| 

| 47COB EXEC PGM=IEQCBLOO 

| Z7SYSUTL DD UNIT=2400, LABEL=(, NL) 

| Second //SYSUT2 DD UNIT=2400, LABEL=(, NL) 

| Procedure //SYSUT3 DD UNIT=2400, LABEL=(, NL) 

| 4/SXYSUT4 DD UNIT=2400, LABEL=(, NL) 

| //SYSPRINT DD SYSOUT=A 

j 4/SYSPUNCH DD SYSOUT=B 

| 

| Delimiter ee ENDUP 

| Statements /* 
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Figure 26. Example of Adding Procedures to the Procedure Library 


Three of the procedures are for use with 
COBOL (F) programs: 


1. COBFC providing compilation, 


2. COBFLG providing linkage editing and 
execution, and 

3. COBFCLG providing compilation, linkage 

editing, and execution. 


These procedures may be used with any of 
the job schedulers released as part of the 
System/360 Operating System. When parame- 
ters required by a particular scheduler are 
encountered by another scheduler not 
requiring those parameters, either they are 
ignored or alternative parameters are sub- 
stituted automatically. For example, if 
these procedures are used with a sequential 
scheduler, the following parameters, which 
are required for multiprogramming with a 
variable number of tasks (MVT), are treated 
as follows: 


REGION=xxxxK is ignored 
SYSOUT=B is interpreted as UNIT=SYSCP 


DISP=SHR is interpreted as 
DISP=(OLD, KEEP) 


These three cataloged procedures are 
shown in Figures 27, 28, and 29. (Space 
allocations in these procedures, are in 
terms of record lengths on the 2311 disk 
storage device.) Note that when DSNAME= 
$name is used in a DD statement, the speci- 
fied data set is given a unique name by the 
operating system, and it is assumed to be a 
temporary data set which will be deleted 
when the job is completed. If the data set 
is to be kept, the DD statement can be 
overridden with a permanent data set name, 
and the appropriate parameters can be 
specified. 


Note: If the compiler options are not 
explicitly supplied with the procedure, 
default options established at the instal- 
lation apply. The programmer can override 
these default options by using an EXEC sta- 
tement that includes the desired options 
(see "“Overriding and Adding to EXEC State- 
ments" later in this chapter). 


Procedure Naming Conventions 


Procedure names begin with the abbre- 
viated name of the processor program, 
which, in the case of the COBOL procedures, 
is COB. 
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The processor's abbreviated name is fol- 
lowed by the level indicator (here F) and 
then by C, L, G or any combination of them. 
The C indicates compile, the L linkage 
edit, and the G go (i.e., execute). Hence, 
procedure COBFC is a single-step procedure 
which compiles a program using the COBOL 
(F) processor; COBFCLG is a three-step pro- 
cedure wherein the first step compiles a 
program using COBOL (F), the second step 


linkage edits the output of the first step, 


and the third step executes the output of 
the linkage editor. 


Step Names in Procedures 


In a cataloged procedure, the step name 
is the same as the abbreviated processor 
name (LKED). The step that executes a conm- 
piled and linkage edited program is named 
GO. 


For example, in the procedure named 
COBFCLG, the first step is named COB, the 
second step is named LKED, and the third 
step is named GO. 


Unit Names in Procedures 


The two unit names used in IBM-supplied 
cataloged procedures are as follows: 


SYSSQ any magnetic tape or direct- 
access device 
SYSDA any direct-access device 


A pool of units must be assigned to 
these unit names during the system genera- 
tion procedure. For example, only 2311 
Disk Storage Drives might be assigned to 
the SYSSQ name. Then again, both 2400 Mag- 
netic Tape Units and 2311 Disk Storage 
Drives might be assigned to the SYSSQ name. 
Once a pool of devices is assigned to these 
classes, device selection is done by the 
Job Scheduler. 


Data_Set Names _in Procedures 


When DSNAME=&name is used in a DD state- 
ment, the specified data set is given a 
unique name by the scheduler, and it is 
assumed to be a temporary data set that 
will be deleted when the job terminates. 
'If the data set is to be retained, the DD 
statement must be overridden with a per- 
manent data set name and appropriate DISP 
parameters. 
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COBFC Procedure 


The COBFC procedure is a single-step 
procedure to execute the COBOL (F) compil- 
er. It produces a punched object deck. 
Figure 27 shows the statements that make up 
the COBFC cataloged procedure. 


The following DD statement must be sup- 
plied in the input stream: 


//COB.SYSIN DD * (or appropriate 
parameters defining an 


input data set) 


If the DD * statement is used under PCP 
the delimiter statement (/*) must follow 
the source module. Under MVT and MFT, the 
(/*) statement is not required. 


COBFLG Procedure 


The COBFLG cataloged procedure is a two- 
step procedure to linkage edit and execute 
the output of a COBOL (F) compilation. 
Figure 28 shows the statements that make up 
the procedure. 


The following DD statement indicating 
the location of the object module must be 
supplied in the input stream: 

//UKED.~SYSIN DD *( or appropriate 
parameters) 


If the COBOL program refers to SYSIN in 
the execution step, the following DD state- 
ment must also be supplied and must be the 
last of the //GO, cards. 

//GO.SYSIN DD *( or appropriate 
parameters) 


If the COBOL program refers to other 
data sets in the execution step such as 
user-defined files, DD statements that 
define these data sets must also be 
provided. 


COBFCLG Procedure 
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The COBFCLG procedure is a three-step 
procedure to compile, linkage edit, and 
execute using the COBOL (F) compiler. 
Figure 29 shows the statements that make up 
the procedure. 


//COB EXEC PGM=IEQCBLOO,PARM=' DECK ,NOLQAD! ,REGION=86K 
//SYSPRINT DD SYSOUT=A 
//SYSPUNCH OD SYSOUT=B 
4/SYSUT1 DD UNIT=SYSCAsSPACE=(460,(700,100)) 
//SYSUT2 DD UNIT=SYSD4,SPACE=(460,(700,100)) 


4/SYSUT3 DD UNIT=SYSDAySPACE=(460,(700,100)) 
SISYSUT4 DD UNIT=SYSOA,SPACE=(460,{700,100)) 





Figure 27. 


//LKED 
//SYSLIN DD DODNAME=SYSIN 


Statements in the COBFC Procedure 


EXEC PGM=IEWLs PARM="*LIST,XREF,LET*® sREGION=96K 


//SYSLMOD DU DSNAME=+GODATA(RUN),DISP=(NEWy PASS), UNIT=SYSDAy 


/f SPACE=(10243 (0505 20,1)) 
//SYSLIB DDB DSNAME=SYS1.COBLIB,sDISP=SHR 


//SYSUT1 DD UNIT=(SYSDAsSEP=(SYSLINySYSLMGD) )ySPACE=(1024, (50,20) ) 


//SYSPRINT DD SYSOQUT=A 
//G0 EXEC PGM=*.eLKED-SYSLMOD,COND=(5,LT,LKED) 
//SYSABEND DD SYSOUT=A 


Figure 28. 


//COB8 EXEC PGM=i1EQ@CBLOO,; REGION=86K 
//SYSPRINT DU SYSOUT=A 

//SYSUTL DD UNIT=SYSCArsSPACE=(460,(700,100)) 
7/SYSUT2 DD UNIT=SYSDAsSPACE=(460,1700,100)) 
//SYSUT3 DD UNIT=SYSDAySPACE=(460,(700;,100)) 
“/SYSUT4 DD UNIT=SYSDA+SPACE=(460,(700,100)) 





Statements in the COBFLG Procedure 


7/SYSLIN DD DSNAME=+LCADSET, DESP=(MOO,PASS), UNIT=SYSDA, 


// SPACE=(80,(500,100)) 


7/LKED EXEC PGM=IEWL, PARM="LIST,XREF,LET' ,COND=(5,LT,COB) »REGION=96K 


7/SYSLIN DG DSNAME=+LOA4DSET, OISP=(OLO,DELETE } 
Jf DD DDNAME=SYSIN 


7/SYSLMOD DB OSNAME=+GODATA(RUN) »DISP=(NEW, PASS) ,UNIT=SYSDA, 


// SPACE=(10242(50s 20;71)) 
//SYSLIB DG DSNAME=SYS1.CUOBL I18,DISP=SHR 


//SYSUT1 DD UNIT=(SYSDAySEP=(SYSLINySYSLMOD) ) » SPACE=(10241150,20)) 


S/SYSPRINT DD SYSOUT=A 


//G0 EXEC PGM=*.LKED.SYSLMOD,COND=((5,LT,COB) s(5yLTyLKED) } 


7/SYSABEND DD SYSOQUT=A 


Figure 29. 


The COB job step produces an object 
module which is input to the linkage edi- 
tor. Other object modules may be added as 
illustrated in Example 5 which appears 
later in this chapter in "Using the DDNAME 
Parameter." 


The following DD statement. indicating 
the location of the source module must be 
supplied in the input stream: 


//COB.-SYSIN DD *( or appropriate 


parameters) 





Statements in the COBFCLG Procedure 


If the COBOL program refers to SYSIN, 
the following DD statement indicating the 
location of the input data set must also be 
supplied: 


//GO.SYSIN DD *( or appropriate 


parameters) 


If the COBOL program refers to other 
data sets, DD statements that define these 
data sets must also be supplied. 
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MODIFYING EXISTING CATALOGED PROCEDURES 


Existing cataloged procedures can be 
permanently modified by using the IEBUPDTE 
utility program described in the publica- 
tion IBM System/360 Operating System: 


Utilities, Form C28-6586. _ 


OVERRIDING AND ADDING TO CATALOGED 
PROCEDURES 


a ee ee ee ee 


Any parameter in a cataloged procedure 
except the PGM=progname parameter in the 
EXEC statement can be overridden. Parame- 
ters or statements not specified in the 
procedure can also be added. When a cata- 
loged procedure is overridden or added to, 
the changes apply only during one 
execution. 


OVERRIDING AND ADDING TO EXEC STATEMENTS 


An EXEC statement can be overridden or 
added to in one of two ways: 


1. Specify, in the operand field of the 
EXEC statement calling the procedure, 
the keyword, the procedure step-name 
and the subparameters, as follows: 


COND. procstep=(subparameters) 


If a multi-step procedure is being 
modified, parameters in the calling 
EXEC statement must be specified step 
by step; i.e., the parameters for one 
step must be specified before those of 
the next step. If the return code of 
a cataloged procedure step is to be 
tested, the name of the step in the 
procedure (procstep) must be qualified 
by the name of the step that called 
for execution of the cataloged proce- 
dure (stepname). 


2. Specify in the operand field of the 
EXEC statement calling the procedure 
only the keywords and subparameters, 
as follows: 


COND=(subparameters) 
If a multi-step procedure is being 
called, the specified parameters (with 
the exception of PARM) apply to all 
steps in the procedure. The PARM key- 
word parameter overrides the first 
EXEC statement and nullifies any sub- 
sequent PARM keyword parameters. The 
COND and ACCT parameters apply to all 
steps in the procedure. To override 
PARM parameters in job steps other 
than the first, the previous method 
can be used. 
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Note: A parameter in an EXEC statement 
cannot be partly overridden; it must be 
overridden in its entirety. Any parameter 
not overridden remains as originally 
defined. 





This section contains examples of over- 
riding and adding to the EXEC statement. 
The procedures overridden or added to are 
the IBM procedures shown in Figures 27, 28, 
and 29. 


Example 1: The following example shows the 
overriding of one parameter in the EXEC 
statement of the one procedure step in the 
IBM-supplied COBFC procedure. The state- 
ments appear in the input stream as follows 
(however, note that in actual use the PARM. 
COB parameter cannot be continued in this 
manner): 


// jobname JOB 1234,3.SMITH 
4/STEPA EXEC COBFC, PARM.COB="DECK, X 
// NOLOAD, BUF=40000° 
//COB.SYSIN DD * 

(source module) 
/* 
Note: In the PARM parameter being overrid- 
den, the DECK and NOLOAD options were spec- 
ified. They are included again since the 
parameter must be overridden in its entire- 
ty. The information is enclosed in single 
quotation marks, since subparameters that 
contain equal signs must be enclosed in 
this manner. 


Example 2 The following example shows the 
overriding of two parameters and the adding 
of another in the EXEC statement of one 
procedure step of the IBM-supplied COBFCLG 
procedure. The statements appear in the 
input stream as shown (however, note that 
in actual use the COND. LKED and PARM. LKED 
parameters cannot be continued in this 
manner) : 


//jobname JOB 123,3.SMITH 

7/STEPA EXEC COBFCLG, COND. LKED= xX 
7/ (9, LT, STEPA.COB), x 
4/ PARM. LKED= X 
4/ (MAP, LIST) , ACCT= (1234) 


4/COB.SYSIN DD * 
(source module) 
/* 


Note: For the linkage editor job step in 
the above example, the COND and PARM param- 
eters have been overridden and the ACCT 
parameter added. 


Example_3: The following example shows the 
overriding of individual parameters in more 
than one procedure step of the IBM-supplied 
COBFCLG procedure. The statements appear 
in the input stream as shown (however, note 
that in actual use the COND.GO statement 
cannot be continued in this manner): 


//jobname JOB 1234,3.SMITH 
//stepname EXEC COBFCLG, PARM.LKED=XREF, X 
td COND. GO=((5,EQ,COB), X 
ad (5, EQ, LKED) ) 


4/COB.SYSIN DD * 
(source module) 
/* 


The PARM option XREF replaces the PARM sub- 
parameters of the linkage editor job step. 

The COND option EQ (equal to) replaces the 

. Option LT (less than) in the execution job 

step. 


Note that all overriding parameters for 
one step of the procedure must be specified 
before those for the next step. 


Example 4: The following example shows the 
overriding of parameters on all EXEC state- 
ments in the IBM-supplied COBCLG procedure. 
The statements appear in the input stream 
as shown: 


//jobname JOB 1234,7.SMITH 

//stepname EXEC COBCLG, PARM=(LOAD, MAP) ,X 
J/ COND= (3, LT) x 
1/7 ACCT= (123456, DEPTQ) 
/7/COB.-SYSIN DD * 


(source module) 
J* 


The PARM options are added to procedure 
step COB and nullify the PARM options in 
the LKED and GO steps. The COND and ACCT 
parameters apply to all steps in the 
procedure. 


OVERRIDING AND ADDING TO DD STATEMENTS 


A DD statement can be overridden or 
added to by using a DD statement whose name 
is composed of the procedure step-name 
which qualifies the ddame of the DD state- 
ment being overridden, as follows: 


(appropriate 
parameters) 


//procstep.ddname DD 


Entire DD statements can also be added. 


There are rules that must be followed 
when oOverriding or adding a DD statement 
within a step in a procedure. 


e Overriding DD statements must be in the 
same order in the input stream as they 
are in the cataloged procedure. 


e DD statements to be added must follow 
overriding DD statements. 


e A DD statement with an * in the operand 
field terminates processing of subse- 
quent DD statements in both the proce- 
dure and the input stream for the job 
step, but not necessarily for the ‘job. 


There are some special cases that should 
be kept in mind when overriding a DD 
statement. 


e All parameters are overridden in their 
entirety, except for the DCB parameter. 
Within the DCB parameter, individual 
subparameters may be overridden. 


e To nullify a keyword parameter (except 
the DCB parameter), write, in the over- 
riding DD statement, the keyword, and 
an equal sign followed by a comma. For 
example, to nullify the use of the UNIT 
parameter, specify UNIT=, in the over- 
riding DD statement. 


e A parameter can be nullified by speci- 
fying a mutually exclusive parameter. 
For example, the SPACE parameter can be 
nullified by specifying the SPLIT 
parameter in the overriding DD 
statement. 


e The DUMMY parameter can be nullified by 
omitting it and specifying the DSNAME 
parameter in the overriding DD 
statement. 


e To override DD statements in a concat- 
enation of data sets, one DD statement 
must be provided for each one in the 
concatenation. The first must be 
named, but all subsequent DD statements 
in the concatenation must not be named. 
If no change is to be made to a DD 
statement placed before one that is to 
be changed, the first overriding 
statement(s) should have a blank 
operand. 


e If the DDNAME=ddname parameter is 
specified in a cataloged procedure, it 
cannot be overridden; rather it can 
refer to a DD statement supplied at the 
time of execution. 


Examples_of Overriding and Adding to DD 


Statements 


This section contains examples of over- 
riding and adding to parameters in DD 
statements. The procedures overridden or 
added to are the IBM procedures shown in 
Figures 27, 28, 29. 
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The DDNAME parameter is not used in 
these examples, although it can be useful 
with the cataloged procedures. The use of 
the DDNAME parameter is described in detail 
later in this chapter. 


Example 1 The following example shows the 
overriding of DD statements in the IBM- 
supplied COBFCLG procedure. 


//jobname JOB 1234,3.SMITH 
//stepname EXEC COBFCLG 
//COB.SYSLIN DD DSNAME=GOFILE 
//COB.SYSIN DD * 


(source module) 


j * 

7/UKED.SYSLIN DD DSNAME=*.COB.SYSLIN, xX 
7/ DISP= (OLD, CATLG) 

/* 


(other DD statements for user-defined 
files) 


/* 


The name of the data set in SYSLIN in the 
procedure step COB is changed to GOFILE. 
The name of the data set of SYSLIN in the 
procedure step LKED is changed to a 
reference to the SYSLIN DD statement in the 
COB procedure step, and the data set name 
GOFILE is cataloged. 


Example 2: The following example shows the 
adding of DD statements to the IBM-supplied 
COBFCLG procedure. Note that if the state- 
ment DD * or the statement DD DATA is used, 
it must be the last to appear in a series 
of DD statements. 


//jobname JOB 1234,J3.SMITH 

//stepname EXEC COBFCLG, 

1/ PARM. COB= (DECK, LOAD, PMAP, COPY) 
//COB.SYSPUNCH DD SYSOUT=B 


//COB.SYSLIB DD DSNAME=USERLIB, DISP=OLD 
4/COB.SYSIN DD * 
(source module) 
/* 
//GO.TRANSACT DD 


DSNAME=JUNE, DISP=OLD 


(other DD statements for user-defined 
files) 
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Note: In the above example SYSLIB and 
TRANSACT are cataloged data sets. When a 
data set is cataloged, it is sufficient to 
refer to it by DSNAME and DISP=OLD. 


The PARM.COB option DECK and the SYSPUNCH 
DD statement are added to obtain a punched 
object module. The PARM option COPY and 
the SYSLIB DD statement are added because 
the source module contains a COPY state- 
ment. The PARM option PMAP is added to 
obtain a listing of the assembler language 
expansion of the source module. 


Example 3: The following example shows 
overriding and adding to DD statements at 
the same time in the IBM-supplied COBFC 
procedure. Note that overriding statements 
must be in the same order as they appear in 
the procedure and must precede those state- 
ments being added. 


//jobname JOB 1234,39.SMITH 

//stepname EXEC COBFC 

//COB. SYSUT2 DD SPACE=, UNIT=SYSSQ, 
//COB.SYSLIN DD DSNAME=&GOFILE, X 
// DISP= (MOD, PASS), X 


1/ UNIT=SYSSQ 
//COB. SYSIN DD * 
(source module) 
/* 
(subsequent job steps) 


The device class on the COB.SYSUT2 DD 
statement is changed to SYSSQ, and the 
SPACE parameter is nullified. Therefore, 
direct-access devices cannot be allocated. 
Any tape volumes to be assigned must have 
Standard labels. The COB.SYSLIN DD state- 
ment is changed so that it passes the 
object module to subsequent job steps. 


Example 4: The following example shows how 
to concatenate a data set with a data set 
defined in the COBFLG procedure. 


//jobname JOB 1234,3.SMITH 
//stepname EXEC COBFLG 


//UKED.SYSLIB DD 
4/ DD 


{blank operand field] 
{parameters] 


/* 


Instead of the blank operand field, parame- 
ters could have been used to override the 
SYSLIB statement; the data set defined by 
the unnamed DD statement would then be con- 
catenated to the data set that was rede- 
fined by overriding. 


Note that any number of libraries could 
be concatenated to the SYSLIB data set. 
For example: 


//LKED.SYSLIB DD 
44 DD DSNAME=USERLIB, DISP=OLD 
// DD DSNAME=MYLIB, DISP=OLD 


USING THE DDNAME PARAMETER 


The DDNAME parameter is used to define a 
dummy data set that can assume the charac- 
teristics of an actual data set, defined by 
a subsequent DD statement within the step. 
If a matching DD statement is found, its 
characteristics, with the exception of its 
ddname, replace those of the statement 
using the DDNAME parameter. If a matching 
DD statement is not found within the step, 
the data set defined by the DDNAME param- 
eter remains a dummy. 


This section contains examples showing 
the use of the DDNAME parameter with cata- 
loged procedures. 


The rules for using the DDNAME parameter 
are as follows: 


e A backward reference (e€.g., *.ddname) 
to a DD statement referred to by a 
DDNAME parameter cannot be used because 
the statement that is referred to loses 
its identity. 


e A backward reference to a statement 
containing a DDNAME parameter can be 
used, but only after the statement to 
which the DDNAME parameter refers has 
been encountered. If a backward 
reference is used before the dummy data 
set (defined by DDNAME) has been given 
real characteristics, these real 
characteristics will not be transferred 
to the DD statement that contains the 
backward reference. For example, if 
DCB=*.ddname is used (where ddname is 
the name of a statement containing an 
unresolved DDNAME parameter), the DCB 
fields that are transferred are blank. 


e Unnamed DD statements can be placed 
after a statement containing the DDNAME 
parameter (indicating concatenation), 
but unnamed DD statements cannot be 
placed after a statement referred to by 
a DDNAME parameter. 


e The DDNAME parameter can be used five 
times in a step, but each DDNAME param- 
eter must refer to a different 
statement. 


e The DDNAME parameter cannot be used in 
a JOBLIB statement. 


When using the DDNAME parameter, the 
following should also be kept in mind. 


e The name of the DD statement referred 
to does not replace the name of the 
referencing statement. 


e If a statement that contains the DDNAME 
parameter is overridden, it is 
nullified. 


e If overriding is performed with a 
statement that contains the DDNAME 
parameter, all parameters in the over- 
ridden statement are nullified. 


The following DD statements: 


7/81 EXEC PGM=progname 

7/01 DD DDNAME=D3 

7/D2 DD (parameters X,Y,2Z) 
4/03 DD (parameters U,T,V) 


will result in the same data definition 
produced by the following statements. 


47751 EXEC PGM=progname 
J/D1 DD (parameters U,T,V) 
4/D2 DD (parameters X,Y,2Z) 


EXAMPLES OF USING THE DDNAME PARAMETER 


Example 1: The following example shows how 
to override the first DD statement ina 
cataloged procedure with a DD * statement, 
and allow subsequent statements to be 
processed. Without the DDNAME parameter, 
replacing the first DD statement with a DD 
* statement would terminate processing of 
subsequent statements in the job step. The 
cataloged procedure (PROC3) is as follows: 


“/STEPL EXEC PGM=progname 
7/DD1 DD (any parameters except *) 
//DD2 DD (any parameters except *) 


The job procedure in which the overriding 
takes place appears in the input stream as 
follows: 


4/T0OB1 JOB 1234,3.SMITH 
7/81 EXEC PROC3 
4/STEP1.DD1 DD DDNAME=D1 
S701 DD * 


The STEP1.DD1 statement overrides the 
DD1 statement; the DD2 statement is 
processed; then the D1 statement is 
processed. 
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Example 2: The following example shows how 
to override the first DD statement in a 
cataloged procedure with a DD * statement 
and how to add a DD statement. The cata- 
loged procedure (PROC3) is as follows: 


//STEP1L EXEC PGM=progname 
/7DD1 DD (any parameters except *) 
//0DD2 DD (any parameters except *) 


The job procedure in which the overriding 
takes place appears in the input stream as 
follows: 


77TOB2 JOB 1234,3.SMITH 

4/81 EXEC PROC3 

7/STEP1.DD1 DD DDNAME=DD4 

4/0DD3 DD (any parameters except *) 
4/DD4 DD * 


The DD4 statement effectively overrides 
the DD1 statement, after the DD2 statement 
has been processed and the DD3 statement 
has been added. 


Example 3: The following example shows how 
to concatenate a data set in the input 
stream with a data set defined by a DD 
statement in a cataloged procedure. The 
cataloged procedure (PROC3) is as follows: 


7/STEPL EXEC PGM=progname 
7/DD1 DD (any parameters except *) 
770D2 DD (any parameters except *) 


The job procedure in which the concatena- 
tion takes place appears in the input 
stream as follows: 


//30B3 JOB 1234,J3.SMITH 

SIS1 EXEC PROC3 

/4/STEP1.DD1 DD (blank operand field) 
17 DD DDNAME=DD3 

7/DD3 DD * 


The data set in the input stream is con- 
catenated with the data set defined by the 
DD1 statement after the DD2 statement has 
been processed. 

Example 4: The following example shows how 
to concatenate a data set in the input 
stream with a data set defined by a DD 
statement in a cataloged procedure and how 
to add a DD statement. The cataloged pro- 
cedure (PROC3) is as follows: 
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//STEP1 EXEC PGM=progname 
//DD1 DD (any parameters except *) 
7/DD2 DD (any parameters except *) 


The job procedure in which the contatena- 
tion takes place appears in the input 
stream as follows: 


//TOBY4 JOB 1234, J.SMITH 

4/81 EXEC PROC3 

//STEP1.DD2 DD (blank operand field) 

4/ DD DDNAME=DD4 

4/DD3 DD (any parameters except *) 
//DD4 DD * 

Example 5: The following example shows how 


the statement DD DDNAME=SYSIN in the IBM- 
supplied COBFCLG procedure can be used to 
add more object modules as input to the 
linkage editor. The statements appear in 
the input stream as follows: 


//jobname JOB 1234,J3.SMITH 
7/stepname EXEC COBFCLG 
//COB.SYSIN DD * 
(source deck) 
/* 
7/LKED.SYSIN DD * 
(first object module) 
(last object module) 
J/* 
(//GO. cards) 


The COBFCLG procedure contains the follow- 
ing two statements in the linkage edit 
step: 


4/SYSLIN DD DSNAME=LOADSET, DISP= Xx 
(OLD, DELETE) 
4/ DD DDNAME=SYSIN 


The result of concatenating SYSIN with 
SYSLIN is that when SYSLIN (input to link- 
age editor) is read, SYSIN is also read and 
linked with it. For example, if IHDFDISP 
is one of the object modules in the SYSIN 
stream, it will be linked with SYSLIN. The 
IHDFDISP module from SYS1.COBLIB will not 
be used. 


The Operating System/360 Checkpoint/ 
Restart feature is designed to be used with 
programs running for an extended period of 
time when interruptions may halt processing 
before the end of the job. The feature is 
available in two operating system environ- 
ments: The PCP (primary control program) 
and MVT (multiprogramming with a variable 
number of tasks). 


The programmer may use the feature to 
offset expected interruptions caused by 
both internal and external causes. For 
instance, he may know that a high-priority 
job is about to be submitted and his pro- 
gram may be interrupted to permit that job 
to run. The feature allows the interrupted 
program to be restarted at the beginning of 
a job step or at a point within a job step. 
The feature consists of two routines: 
Checkpoint and Restart. 


The Checkpoint routine is invoked by the 
COBOL load module containing the user's 
program. It moves information stored in 
registers and in main storage into a check- 
point record at user-designated points dur- 
ing execution of the program. The pro- 
grammer specifies these points using the 
COBOL RERUN clause in the Environment 


Division. 


rupted program which has previously written 
a checkpoint record. The checkpoint record 
will contain all information necessary to 
restart the program. Restart can be 
initiated at any time after the program was 
interrupted; that is, it may be run immedi- 
ately after the interrupt occurred, as an 
automatic restart, or at some later time 
convenient to the programmer, as a deferred 
restart. 


The COBOL RERUN clause provides linkage 
to the system checkpoint routine. Hence, 
any cautions and restrictions on the use of 
the system checkpoint/restart feature also 
apply to the use of the RERUN clause. 


The Checkpoint/Restart feature is fully 
described in the publication IBM System/360 
Operating System: _Supervisor_and_ Data 
Form C28-6646,. 


In order to initiate a checkpoint, the 
programmer uses Job Control statements and 
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COBOL RERUN clauses. The programmer asso- 
ciates each RERUN clause with a particular 
COBOL file. The RERUN clause indicates 
that a checkpoint record is to be written 
onto a checkpoint data set whenever a spec- 
ified number of records on that file have 
been processed. The programmer must define 
the checkpoint data set on a DD statement. 
The DD statement describes both a check- 
point data set and a checkpoint method. 


CHECKPOINT METHODS 


The programmer may elect to take single 
or multiple checkpoints, as described 
below: 


Single: Only one checkpoint record exists 
at any given time. After the first check- 
point record is written, any succeeding 
checkpoint record overlays the previous 
one. This method is acceptable for most 
programs. It offers the advantage of sav- 
ing space on the checkpoint data set and 
allows the programmer to restart his pro- 
gram at the latest checkpoint. 


Multiple (multiple contiguous): Check- 


points are recorded and numbered sequen- 
tially. Each checkpoint is saved. This 
method is used when the programmer may wish 
to restart a program at a checkpoint other 
than at the latest one taken. 


DD STATEMENT FORMATS 


The programmer records checkpoints on 
tape or direct-access devices. Following 
are the DD formats to define checkpoint 


data sets. For Tape: 

7/dadname DD DSNAME=data-set-name, X 

// VOLUME=SER=volser, X 

// UNIT=deviceno, X 

71 pane eee eee X 
MOD 

4/ DCB= (TRTCH=C) , LABEL= (, NL) 

For Direct Access: 

//ddname DD DSNAME=data-set~—name, X 

71 VOLUME= (PRIVATE, RETAIN, SER=volser), X 

17 UNIT=deviceno, DISP= (NEW, KEEP), X 


// SPACE= (TRK, nnn) 
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where: 


ddname 
is the same as the external-name used 
in the COBOL RERUN clause to provide a 
link to the DD statement. 


data-set-name 
is the name given to each particular 
data set used to write checkpoint 
records. This name identifies the 
checkpoint data set at the Restart 
procedure. (See "Restarting a Pro- 
gram" in this section.) 


volser 
identifies the volume by serial 
number. 


deviceno 
identifies the device. For tape it 
indicates the device number for 7- 
track or 9-track tape. For direct 
access, it indicates the device number 
for disk or drum. 


MOD 
is specified for the multiple contig- 
uous checkpoint method. 


NEW 
is specified for the single checkpoint 
method. 


KEEP 
is specified in order to prevent dele- 
tion of the data set at the conclusion 
of the job step. 


nnn 
is a decimal number indicating the 
number of tracks to be allocated to 
the checkpoint data set. The number 
of tracks required will depend on two 
factors. 


1. whether single or multiple check- 
points are taken 


2. the size of main storage (larger 
main storage requires more check- 
point records be written). 


Note: The DCB parameter is necessary only 
for 7-track tape conversion; for 9-track 
tape it is not used. 





Following are examples in defining 
checkpoint data sets. 


To write single checkpoint records using 
tape: 
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peeiries eet ead tas eee ess 
|//CHECKPT DD DSNAME=CHECK1, X 
\// VOLUME=SER=ND003, X 
1// UNIT=2400,DISP=(NEW,KEEP),  X 
|// LABEL=(, NL) 


l 

| 

| ENVIRONMENT DIVISION 
| . 

. 

| 
] 
l 


RERUN ON 'CHECKPT' EVERY 500 RECORDS 
OF ACCT-FILE. 


To write single checkpoint records using 
disk (note that more than one data set may 
share the same external-name): 


Ce GO ae Co Cane Pee ae ge ok Vrca ea ee 1 
| // CHEK DD DSNAME=CHECK2, x | 
|/7 VOLUME= (PRIVATE, RETAIN, SER=111111) x| 
1/7 UNIT=2314, DISP= (NEW, KEEP), xX | 


\// SPACE= (TRK, 300) 


ENVIRONMENT DIVISION 


PAYCODE. 
RERUN ON ‘CHEK' EVERY 300 RECORDS OF 


| 
| 
| 
| 
| 
: | 
| 
| 
| 
| 
| 
IN-FILE. l 


| 
| 
| 
i 
| 
| 
| RERUN ON 'CHEK' EVERY 200 RECORDS OF 
| 
| 
| 
Lo 


To write multiple contiguous checkpoint 
records (on tape): 


|//CHEKPT DD DSNAME=CHECK3, x 
|// VOLUME=SER=11111, x 
\// UNIT=2400, DISP=(MOD, KEEP), x 


\// LABEL= (, NL) 


| 

| 

| ENVIRONMENT DIVISION 
| ° 

| . 

| 
| 


RERUN ON ‘CHEKPT' EVERY 100 RECORDS 
OF PAY-FILE. 


The system checkpoint routine advises 
the operator of the status of the check- 
points taken by displaying information mes- 
sages on the console. 


When a checkpoint has been successfully 
completed, the following message will be 
displayed: 


IHJOO4I jobname (ddname, unit, volser) CHKPT 
checkid 


where checkid is the identification name of 
the checkpoint taken. Checkid is assigned 
by the control program as an 8-digit field. 
The first digit is the letter C, followed 
by a decimal number indicating the check- 
point. For example, checkid C0000004 indi- 
cates the fourth checkpoint taken in the 
job. 


PLANNING CHECKPOINTS 


The programmer should give some thought 
to planning his checkpoints so that they 
become an integral part in the overall 
efficiency of his program. Some considera- 
tions in deciding how best to implement the 
checkpoint facility follow. 


1. Timing. Whenever a checkpoint is 
taken, a small delay is encountered in 
processing the problem program. 
Checkpoints taken too often will 
impact the processing time of a pro- 
gram. A programmer should decide 
whether he can afford to take check- 
points on a certain time schedule, 
e.g., every twenty or thirty minutes, 
or if he should take checkpoints more 
frequently. 


2. Data reconstruction. In programs 
using direct-access files, changes to 
records will replace previous informa- 
tion; after processing, a record may 
bear little resemblance to the record 
it updated. Thus the programmer 
should be sure he can identify pre- 
viously processed records. For 
example, assume that a direct-access 
dévice contains a user file consisting 
of loan records which are periodically 
updated to reflect interest due. If a 
checkpoint is taken and other addi- 
tional records are updated and then an 
interruption occurs, the records 
updated after the last checkpoint will 
be updated again when the program is 
restarted, unless the programmer con- 
trols this condition. (He may set up 
a date field for each record and 
update the date each time the record 
is processed. Then, by investigating 
the date field after the restart, he 
can determine whether or not the 
record was previously updated.) 


RESTARTING A PROGRAM 


The system Restart routine retrieves the 
information recorded in a checkpoint 
record, restores the contents of main 
storage and all registers, repositions tape 


and direct-access devices, and then gives 
control to the COBOL load module. Restart 
can occur in one of two ways. It may occur 
automatically at the time an interruption 
stopped the program, or it may be initiated 
at a later time as a deferred restart. The 
type of restart is determined by the RD 
parameter of the job control language. 


THE RD PARAMETER 


The RD parameter may appear on either 
the JOB or the EXEC statement. If coded on 
the JOB statement, the parameter overrides 
any RD parameters on the EXEC statement. 


If the programmer wishes to have his 
program restart automatically, he codes 
RD=R or RD=RNC. RD=R indicates that 
restart is to occur at the latest check- 
point. The programmer should specify the 
RERUN clause for at least one data set in 
his program in order to record checkpoints. 
If no checkpoint is taken prior to inter- 
ruption, restart occurs at the beginning of 
the job step. RD=RNC suppresses the writ- 
ing of a checkpoint record; thus any 
restart will occur at the beginning of the 
job step. RERUN clauses are unnecessary; 
if any are present, they are ignored. 


If the programmer wishes to suppress 
automatic restart, he codes RD=NR or RD=NC. 
RD=NR suppresses automatic restart but 
allows a checkpoint record to be written, 
provided a RERUN clause has been specified. 
At restart time, the programmer may choose 
to restart his program at a checkpoint 
other than at the beginning of the job 
step. RD=NC suppresses both restart and 
checkpoints. In effect, the programmer is 
ignoring the features of the Checkpoint/ 
Restart facility. 


AUTOMATIC RESTART 


Automatic restart occurs only at the 
latest checkpoint taken. (If no checkpoint 
was taken before interruption, automatic 
restart occurs at the beginning of the job 
step.) 


In order to restart automatically, a 
program must request restart through use of 
the RD parameter, and must receive authori- 
zation from the operator. The system dis- 
plays the following message to request 
authorization of the restart: 


xxIEF225D SHOULD jobname. stepname. procstep 
RESTART [checkid] 
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The operator will reply in the following 
form: 


REPLY xx, ‘{YES]NO]HOLD}' 


where YES authorizes restart, NO prevents 
restart, and HOLD defers restart until the 
operator issues a RELEASE command, at which 
time restart will occur. The HOLD option 
is applicable only in the MVT environment. 


Whenever automatic restart is to occur, 
the system will reposition all devices 
except unit record devices. With the PCP 
environment, the operator should manually 
reload any input card deck into the card 
reader. 


DEFERRED RESTART 


Unlike an automatic restart, a deferred 
restart may occur at any checkpoint, not 
necessarily the latest one taken. 


The programmer requests a deferred 
restart by means of the RESTART parameter 
on the JOB card and, if restart is to occur 
at a particular checkpoint within a job 
step, a SYSCHK DD statement to identify the 
checkpoint data set. The formats for these 
statements are as follows: 


/fjobname JOB ,MSGLEVEL=1, X 
// RESTART= (request, ([checkid] ) 
//SYSCHK DD DSNAME=data-Set-name, Xx 
4/ DISP=OLD, UNIT=deviceno, X 
//4 DCB=(, RECFM=U, BLKSIZE=nnnn) , X 
4/7 VOLUME=SER=volser 

where: 

MSGLEVEL=1 


is required if restart is to occur in 
an MVT environment 


RESTART=(request, [checkid]) 
identifies the particular checkpoint 
at which restart is to occur. Request 
may take one of the following forms: 


* to indicate restart 
at the beginning 
of the job. 
stepname to indicate restart 


at the beginning 
of a job step. 


stepname.procstep to indicate restart 
at a procedure 
step within the 
job step. 


checkid 


identifies the checkpoint where 
restart is to occur. 
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SYSCHK 
is the DDNAME used to identify a 
checkpoint data set to the control 
program. The SYSCHK DD statement must 
immediately precede the first EXEC 
statement of the resubmitted job. 


data-set-name 
must be the same name that was used 
when the checkpoint was taken. It 
identifies the checkpoint data set. 


deviceno and volser 
identify the device and volume con- 
taining the checkpoint data set. 


nnnn 
is a decimal number identifying the 
block size in bytes. The number must 
not be smaller than 600 and not larger 
than 32,760. 


As an example illustrating the use of 
these job control statements, a restart of 
the GO step of a COBFCLG procedure, at 
checkpoint identifier C0000003, might 
appear as follows: 


//jobname JOB ,MSGLEVEL=1, x 
71 RESTART= (GO, C0000003) 
//SYSCHK DD DSNAME=CHEKPT, x 
// DISP=OLD, UNIT=2400, X 
4/ VOLUME=SER=111111, x 
1/ DCB=(, RECFM=U, x 
// BLKSIZE=3625) 

//procstep EXEC COBFCLG 


DD statements similar to original deck 


The Restart routine uses information 
from DD statements in the resubmitted job 
to reset files for use after restart; 
therefore, care should be taken with any DD 
statements that may affect the execution of 
the restarted job step. Attention should 
be paid to the following: 


e During the original execution, a data 
set meant to be deleted at the end of a 
job step should conditionally be 
defined as KEEP rather than DELETE in 
order to be available if an interrup- 
tion forces a restart. 


e At restart time, a data set created in 
the original execution (defined as NEW 
on a DD statement) should be defined as 
OLD or have a unique name assigned to 
it. 


e At restart time, input data sets on 
cards should be positioned as they were 
at the time of the checkpoint. Cards 
which were read in before the check- 
point should not be read in again. 
Input data sets on tape or direct- 


access devices will be automatically 
repositioned by the system. 


e At restart time, the EXEC statement 
parameters PGM and COND and the DD 
statement parameters SUBALLOC and 
VOLUME=REF must not be used in steps 
following the restart step if they con- 
tain the form stepname or step- 
name.procstep referring to a step pre- 
ceding the restart step. 


When a deferred restart has been suc- 
cessfully completed, the system will dis- 
play the following message on the console: 

IHJOO08I jobname RESTARTED 


and gives control to the user's program. 
THE CHECKPOINT MACRO INSTRUCTION (CHKPT) 


A checkpoint is taken by using the 
operating system macro instruction, CHKPT. 


The format of the instruction used by COBOL 
is: 


CHKPT BSAMDCB 


The format of the data control block (DCB) 
used by COBOL to describe the checkpoint 
data set is: 


BSAMDCB DCB DSORG=PS, MACRF=W, 
RECFM=U, DEVD=DA, DDNAME=DUMMY 


COBOL allows the operating system check- 
point routines to open and close the check- 
point data set at each checkpoint. COBOL 
does not specify a BLKSIZE parameter in the 
DCB, therefore permitting a DD statement 
specification or, by default, the maximum 
size record allowed on the device. The 
ddname specified in the user's checkpoint 
data set DD statement is substituted for 
DDNAME=DUMMY. 
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The compiler, linkage editor, COBOL load 
module, and other system components can 
produce output in the form of printed list- 
ings, punched card decks, diagnostic or 
informative messages and data sets directed 
to tape or direct-access devices. This 
chapter describes the output listings which 
can be used to document and debug programs 
and the format of the output modules. The 
same COBOL program is used for each 
example. Appendix A shows the output for- 
mats in the context of a complete listing 
generated by a sample program. 


COMPILER OUTPUT 


The output of the compilation job step 
may include: 


¢ A printed listing of the job control 
statements 


e Device allocation messages from the job 
scheduler 


e A printed listing of the statements 
contained in. the source module 


e A glossary of compiler-generated infor- 
mation about data 


//30B3 JOB 
//STEP3 
//SYSUT1 DD 
//SYSUT2 DD 

(1) //SYSUT3 DD 
//SYSUT4& DD 
//SYSLIN DD 
// DISP=(NEW,PASS) 
//SYSPRINT DD SYSOUT=A 
//SYSIN DD # 


IEF236I ALLOC. FOR JOB3 
IEF237I SYSUT1 ON 190 
IEF2371 SYSUT2 ON 190 
(2) IEF2371 SYSUT3 ON 190 
IEF2371 SYSUT4 ON 190 
IEF2371 SYSLIN ON 190 
IEF2371 SYSIN ON OOC 


STEPS 


Figure 30. 


PROGRAMMERNAME »MSGLEVEL=1 
PGM=IEQCBLOO, PARM=' BUF=13000,SIZE=160000,MAP! 
DSNAME=6UT1,UNIT=SYSDA,SPACE=(TRK, (100,10)) 
DSNAME=6UT2,UNIT=SYSDA;SPACE=(TRK,(100,10)) 
DSNAME=6UT3,UNIT=SYSDA,SPACE=(TRKy (100,10) ) 
DSNAME=E&UT4,UNIT=SYSDA, SPACE=(TRKy (100,10) ) 
DSNAME=PUNCH,UNIT=SYSDA,SPACE=(TRK,(100,10)); X 


OUTPUT 


e A printed listing of the object code 
e Compiler diagnostic messages 
e System messages 


® Disposition messages from the job 
scheduler 


e An object module 


Diagnostic messages associated with the 
compilation of the source program are auto- 
Matically generated as output. The other 
forms of output may be requested in the 
PARM parameter in the EXEC statement. The 
level of diagnostic messages printed 
depends upon the FLAGW or FLAGE options. 


All output to be listed is written on 
the device specified by the SYSPRINT DD 
statement. Line spacing of the source 
listing and the number of lines per page 
can be controlled by the SPACEn and LINECNT 
options. 


Figure 30 contains the compiler output 
listing shown in Appendix A. Each type of 
output is numbered, and each format within 
each type is lettered. The text following 
the figure is an explanation of the figure. 


Examples of Compiler Output (Part 1 of 3) 
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Figure 30. 


98 


00018 
00019 
00020 
00021 
00022 
00023 
00024 
00025 
00026 


00053 
00054 
00055 
00056 


00057 
00058 
00059 
00060 
00061 


00077 
00078 


® 


57 


57 


57 


61 


100180 
100190 
100200 
100210 
100220 
100230 
100240 
100250 
100260 


100530 
100540 
100550 
100560 


100570 
100580 
100590 
100600 
100610 


100770 
100780 


@) 


DATA DIVISION. 
FILE SECTION. 
FD FILE-1 
LABEL RECORDS ARE OMITTED 
BLOCK CONTAINS 100 CHARACTERS 
RECORDING MODE IS F 
DATA RECORD IS RECORD-1. 
O01 RECORD-1. : 
02 FIELD-A PICTURE IS xX(20). 


PROCEDURE DIVISION. 


BEGIN. READY TRACE. 
NOTE THAT THE FOLLOWING OPENS THE OUTPUT FILE TO BE CREATED 


AND INITIALIZES COUNTERS. 


STEP-1. OPEN OUTPUT FILE~1. MOVE ZERO TO COUNT, NUMBER. 
NOTE THAT THE FOLLOWING CREATES INTERNALLY THE RECORDS TO BE 
CONTAINED IN THE FILE, WRITES THEM ON TAPE, AND DISPLAYS 


THEM ON THE CONSOLE. 
STEP-2. ADD 1 TO COUNT, ADD 1 TO NUMBER, MOVE ALPHA (COUNT) TO 


STEP-8. CLOSE FILE-2 . 
STOP RUN. 


® © OQ © © ©) 


INTRNL NAME LVL SOURCE NAME BASE DISPL INTRNL NAME DEFINITION 


DNM=1-146 FO FILE-1 DCB=01 DNM=1-146 
DNM=1=-164 01 RECORD=-1 BLI=1 000 DNM=1-164 OS OCL20 
DNM=1-184 02 FIELD-A BLI=1 000 ONM=1-184 OS 20C 


@) MEMORY MAP 
TGT 00160 
SAVE AREA 00160 
SWITCH CELL 001 A8 
TALLY CELL OOLAC 
UNUSED 00180 
LITERAL POOL (HEX) 
00358 (LIT+0) 00000001 OO1AFOE9 C0000000 


DISPLAY LITERALS (BCD) 


00364 (LTL+12) "WORK~RECORD* 


© 


PGT 09318 
OVERFLOW CELLS 00318 
VIRTUAL CELLS 00318 
PROCEDURE NAME CELLS 0031C 
GENERATED NAME CELLS 00330 
DCB ADDRESS CELLS 00348 
VNI CELLS 00350 
LITERALS 00358 
DISPLAY LITERALS 00364 


© © © © 


*STEP=1 
000384 58 FO C 000 L 15,000(0,12) 
000388 05 1F BALR) 1,15 
00038A 000140 oc X*0001405 
000380 O5E2E3C5D760F1 oc X*OSE2E3C5D760F1® 

OPEN 000394 58 10 C 030 L 1,030(0,12) 
000398 50 10 D 1AC ST 1,1AC(0,13) 
00039C 92 8F D LAC MVI 1AC(13),X*8F8 
0003A0 41 10D LAC LA 1,1AC(0,13) 
0003A4 OA 13 Svc 19 
0003A6 58 10 C 030 L 1,030(0,12) 
OO03AA 58 FO 1 030 L 15+030(0;1) 
QOOSAE O05 EF BALR) 14,15 
0003B0 5010 D 198 ST 1,198(0,13) 
0003B4 58 70 D 198 t 719198(0,13) 
MOVE siete D2 O01 6 000 C 040 MVC 000(236)1040(12) 
E D2 01 6 O1C . 

geregas C 040 MVC 010(256)+040(12) 
0003C4 PN=01 EQU * 
0003C4 58 FO C 000 L 15,000(0,12) 


Examples of Compiler Output (Part 2 of 3) 


USAGE R 
QSAM 
GROUP 
DISP 


© 


VC THDFDISP) 


DCB=1 
PRM=1 
P2M=1 
PRM=1 


DCB=1 
BLI=1 
BLI=1 


ONM=1-257 
DNM=1-305 


VCTHDFIISP) 


LIT+0 
LIT+0 


@ 


@) ®©@ © © 


CARD ERROR MESSAGE 

@ 77 1EQ10801-W PERIOD PRECEDED BY SPACE. 
IEF2851  UT1.JOB3 
IEF2851 VOL SER NOS= 111111. 
IEF2851 UT2.JOB3 
IEF285I VOL SER NOS= 111111. 
IEF285I UT3.JOB3 

IEF285I VOL SER NOS= 111111. 
IEF285I1 UT4.J0B3 
IEF2851 VOL SER NOS= 111111. 
IEF2851 PUNCH 
IEF2851 VOL SER NOS= 111111. 
IEF285I1 SYSQUT 
IEF2851 VOL SER NOS= SCRTCH. 

Figure 30. Examples of Compiler Output 


The listing of the job control state- 
ments associated with this job step. 
These statements are listed because 
MSGLEVEL=1 is specified in the JOB 
statement. 


Allocation messages from the job 
scheduler. These messages provide 


information about the device alloca- 
tion for the data sets in the job 
step. They appear after the job con- 
trol statements in the compile, lin- 
kage editor, and execution job steps. 
For example: 

IEF2371 SYSUT1 ON 190 

indicates that the data.set for SYSUT1 
has been assigned to the device 190. 


The source module listing. The state- 
ments in the source module are listed 


exactly as submitted except that a 
compiler-generated card number is 
listed in the first column of each 
line. This number is referred to ina 
diagnostic message and in the object 
code listing. The source module is 
not listed when the NOSOURCE option is 
specified. 


The following notations may appear on 
the listing: 


Cc 


** 


Denotes that the statement was 
inserted with a COPY or INCLUDE 
statement. 


Denotes that the card is out of 
sequence. 


DELETED 
DELETED 
DELETED 
DELETED 
PASSED 


SYSOUT 


I 


ASSUME END OF SENTENCE. 


(Part 3 of 3) 


Denotes that the card was inserted 
with an INSERT or BASIS card. 


If DATE-COMPILED is specified in the 


Identification Division, 


that 


any sentences in 
paragraph are replaced in the listing 


by the date of compilation in the following 
format: 


® 


DATE-COMPILED. month day year 

The glossary: The glossary is listed 
when the MAP or DMAP option is speci- 
fied. The glossary contains informa- 
tion about names in the COBOL source 
program. 


A and Fe. The internal name generated 
by the compiler. This name is 
used in the compiler object code 
listing to represent the name used 
in the source program. 


A normalized level number. This 
level number is determined by the 
compiler as follows: the first 
level number of any hierarchy is 
always 01, and increments for 
other levels are always by one. 
Only level numbers 03 through 49 
are affected; level numbers 77 and 
88 and FD, SD, and RD indicators 
are not changed. 


The data name that is used in the 
source module. 


C. 


Note that the following Report Writer 
internally generated data-names can 
appear under the SOURCE NAME column: 
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CTL.LVL - Used to keep track of con- 
trol levels. 

GRP.IND - Used by coding for GROUP 
INDICATE clause. 

TER.COD - Used by coding for 


TERMINATE. 
FRS.GEN - Used by coding for GENERATE. 
-nnnn -~ Generated report record 


associated with the file 
on which the report is to 
be printed. 

RPT.RCD - Build area for print record. 

CTL.CHR - First or second position of 
RPT.RCD. Used for car- 
riage control character. 

RPT.LIN - Beginning of actual informa- 
tion which will be dis- 
played. Second or third 
position of RPT.RCD. 

Eennnn - Field within RPT.RCD. Over- 
lays part of RPT.RCD, 
depending on the column 
clause. 

S.ennnn - Used for elementary level 

with SUM clause, but not 
with data name. 

Nennnn - Used to save the total 
number of lines used by a 
report group when relative 
line numbering is 
specified. 


Dand E. For data names, these 
columns contain information about 
the address in the form of a base 
and displacement. For file names, 
the column contains information 
about the associated DCB and DECB, 
if any. 


G. This column defines storage for 
each data item. It is represented 
in assembler-like terminology. 
Table 10 refers to information in 
this column. 


H. Usage of the data name. For FD 
entries, the file organization is 
identified. For group items con- 
taining a USAGE clause, the infor- 
mation in the clause is identi- 
fied. For group items not con- 
taining a USAGE clause, GROUP is 
identified. For elementary items, 
the information in the USAGE 
clause is identified. 


I. An asterisk under column: 


R-Indicates that the data-name 
redefines another data-name. 
O-Indicates that an OCCURS clause 
has been specified for that 
data-name. 

Q-Indicates that the data-name is 
or contains the DEPENDING ON 
object of the OCCURS clause. 


Global_tables_and literal pool: The 
Global table is listed when the MAP or 
PMAP option is specified unless SUPMAP 
was specified and an E-level diag- 
nostic was generated. A global table 
contains easily addressable informa- 
tion needed by the object program for 
execution. For example, in the Proce- 
dure Division output coding (3) the 
address of the first instruction under 
STEP-1 (OPEN OUTPUT FILE-1) would be 
found in the PROCEDURE NAME CELLS por- 
tion of the Program Global Table 
(PGT). 


A. The Task Global Table (TGT). This 
table consists of switches, 
addresses and work areas used by 
the in-line program. Subtask 
Global Tables (SGT) contain simi- 
lar information used by the random 
processing procedures. One TGT 
exists for the entire program; one 
SGT exists for each random 
processing procedure. 


C. The Program Global Table (PGT). 
This contains the remaining ad- 
dresses and the literals used by 
the object program. 


The literal pool (B) lists the collec- 
tion of the literals in the progran, 
with duplications removed. These 
literals include those specified by 
the programmer (e.g., MOVE ‘ABC TO 
DATA-NAME) and those generated by the 
compiler (e.g., to align decimal 
points in arithmetic computation). 

The literals are divided into two 
groups: those that are referred to by 
instructions (marked "LITERAL POOL") 
and those that are referred to by the 
calling sequences to object time sub- 
routines (marked "DISPLAY LITERALS"). 


The_object code listing: The object 
code listing is produced when the MAP 
or PMAP option is specified. The 


actual object code listing contains: 


A. The compiler-generated card 
number. The number refers to the 
COBOL statement in the source 
module which contains the verb 
that is listed under column B. 


B. The COBOL procedure-name and the 
COBOL verb. The procedure-name is 
indicated by an asterisk. 


The statement within which the 
COBOL verb appears determines the 
information under columns C, D, F, 
and G. 


Table 10. Glossary Definition and Usage 


a ea eT ee i i aa eracloe ene screen iaa al e No ns ee OO ee 1 
] Type ] Definition {| Usage | 
~~--~-~------------------ }--------~------- =} -- === === $$ == n=] 
]|GROUP FIXED LENGTH ] DS OCLNC | GROUP 
] ALPHABETIC | DS NC ] DISP | 
| ALPHANUMERIC | DS NC | DISP | 
{GROUP VARIABLE LENGTH | DS VLI=N } GROUP | 
| REPORT | DS NC | RPT 
| STERLING REPORT { DS NC | RPT-sT | 
| EXTERNAL DECIMAL |} DS NC | DISP-NM | 
{EXTERNAL FLOATING POINT | DS NC | DISP-FP | 
| INTERNAL FLOATING POINT | DS 1F } COMP-1 | 
i |} Ds 1D | COMP-2 | 
| BINARY ] DS 1H, 1F OR 2F | COMP | 
J INTERNAL DECIMAL | DS NP | COMP-3 | 
| STERLING NON-REPORT } DS NC | DISP-ST | 
| | | | 
| FILE (FD) | RPD=0 | FILE PROCESSING TECHNIQUE | 
|CONDITION (88) ] BLANK | BLANK 
]REPORT DEFINITION (RD) | BLANK | BLANK | 
|SORT DEFINITION (SD) ] BLANK | BLANK 
Wits eti cee ete ores aia desneee nee e eee bo Se eee ee See eek 


-|Under the definition column, N= size in bytes, except in group variable length where it] 


jis a variable length cell number. 


Cc. The relative location, in hexadec- 
imal notation, of the object code ®) 
instruction in the module. 


D. The actual object code instruction 
in hexadecimal notation. 


Ee The procedure-name number. A 
number is assigned only to 
procedure-names referred to in 
other Procedure Division 
statements. 


F. The object code instruction in the 
form that closely resembles 
assembler language (displacements 
are in hexadecimal notation). 


G. Compiler-generated information 
about the operands of the 
generated instruction. This 
includes names and relative loca- 
tions of literals. Table 11 
refers to information in this 
column. 


Note: The programmer can produce a con- 
densed listing by specifying CLIST as an 
option in place of MAP or PMAP. The CLIST 
option produces only the source card num- 
ber, the EBCDIC representation of the verb 
name, and the location of the first gener- 
ated instruction, as follows: 


54 READY 000380 57 OPEN 000394 
a7 MOVE 0003B8 64 ADD 000444 
61 ADD 000450 61 MOVE 00045C 


Diagnostic messages: The diagnostic 


messages associated with the compila- 
tion are always listed. The format of 
the diagnostic message is: 


A. 


C. 


Compiler-generated line number. 
This is the number of a line in 
the source module related to the 


error. 


Message identification. The mes- 
sage identification for COBOL (F) 
compiler diagnostic messages 
always begins with the symbols 


IEQ. 


The severity level. There are 
four severity levels as follows: 


W 


Warning - This level indi- 
cates that an error was made 
in the source program. 
However, it is not serious 
enough to hinder the execu- 
tion of the program. These 
Warning messages are listed 
only if FLAGW is specified. 


Conditional - This level in- 
dicates that an error was 
made but the compiler usual- 
ly makes a corrective 
assumption. The statement 
containing the error is 
retained. Execution can be 
attempted for the debugging 
value. 
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Table 11. 


Symbols Used in the Listing and 
Glossary to Define Compiler- 
Generated Information 


ee ee ee a we ee ewe wn we wee we ww wow ee 1 


. 
{Symbol Meaning 


| 

Paes een tar enee cero em eee Sa fea ee ee en 4 
| DNM SOURCE DATA NAME { 
| SAV SAVE AREA CELL j 
| Swt SWITCH CELL | 
| TLY TALLY CELL | 
| wc WORKING CELL | 
iTS TEMPORARY STORAGE CELL i 
| SBI SECONDARY BASE LOCATOR | 
| BLI BASE LOCATOR | 
| BLL BASE LOCATOR FOR LINKAGE SECTION {| 
| On ON COUNTER { 
| PFM PERFORM COUNTER | 
{Psv PERFORM SAVE | 
| VN VARIABLE PROCEDURE NAME { 
| DEC DECB ADDRESS | 
| SBS SUBSCRIPT ADDRESS | 
| XSW EXHIBIT SWITCH j 
| XSA EXHIBIT SAVE AREA | 
| PRM PARAMETER i 
| PN SOURCE PROCEDURE NAME | 
| GN GENERATED PROCEDURE NAME | 
| DCB DCB ADDRESS | 
| VNI VARIABLE NAME INITIALIZATION | 
| LTL LITERAL | 
| TS2 TEMPORARY STORAGE (NON-ARITHMETIC) | 
| RSV REPORT SAVE AREA | 
| SAV2 SAVE AREA 2 j 
|SAV3 SAVE AREA 3 | 
| V(BCD-N) VIRTUAL | 
Mea a a ae J 
E Error - This level indicates 


102 


De 


that a serious error was 
made. Usually the compiler 
makes no corrective assump- 
tion. The statement or 
operand containing the error 
is dropped. Execution of 
the program should not be 
attempted. 


D Disaster - This level in- 
dicates that a serious error 
was made. Compilation is 
not completed. Results are 
unpredictable. 


There is a correlation between 
severity level and the return 
codes referred to by the COND 
parameter. For example, a compi- 
lation in which a D-level error is 
detected will generate a return 
code of 16. 


The message text. The text iden- 
tifies the condition that caused 
the error and indicates the action 
taken by the compiler. 


Since Report Writer generates a 
number of internal data items and 
procedural statements, some error 


messages may reflect internal 
names. In cases where the error 
manifests itself mainly in these 
generated routines, the error mes- 
sages may indicate the card number 
of the RD entry for the report 
under consideration. In addition, 
there are errors that may indicate 
the card number of the card upon 
which the statement containing the 
error ends rather than the card 
upon which the error occurred. 


Internal name formats for Report 
Writer are discussed under 
Glossary. 


A complete list of compiler diag- 
nostic messages is contained in 
the last appendix in this 
publication. 


Disposition messages from the job 
scheduler: These messages contain 


information about the disposition of 
the data sets, including volume serial 
numbers of volumes in which the data 
sets resides. 


THE OBJECT MODULE 


The object module contains the external 
symbol dictionary, the text of the program, 
and the relocation dictionary. It is fol- 
lowed by an END statement that marks the 
end of the module. For more detailed 
information about the external symbol dic- 
tionary, text, and relocation dictionary 
refer to the publication IBM System/360 
System: Linkage Editor, Form 


C28-6538. 


An object module deck is punched if the 
DECK option is specified unless SUPMAP was 
specified and an E-level diagnostic was 
generated, and if a SYSPUNCH DD Statement 
is included. An object module is written 
in an output volume if the LOAD option is 
specified unless SUPMAP was specified and 
an E-level diagnostic was generated, and if 
a SYSLIN DD statement is included. 


LINKAGE EDITOR OUTPUT 


The output of the linkage editor job 
step may include: 


e A printed listing of the job control 
statements 


e A map of the load module after it has 
been processed by the linkage editor 


e A cross reference list 
e Informative messages 

e Diagnostic messages 

e Disposition messages 


e A listing of the linkage editor control 
statements 


A load module which must be assigned to 
a library 


Any diagnostic messages or informative 
messages associated with the linkage editor 


4ASTEP4 EXEC 
//SYSUT1 DD 
//SYSLMOD DD 
// 

//SYSLIB DD 
7/SYSPRINT DD 
//SYSLIN DD 
// 


‘PGM=IEWL, PARM='XREF' 


DISP=(NEW, PASS) 
DSNAME=SYS1.-COBLIB;DISP=OLD 
SYSOUT=A 


DISP=(OLD,DELETE) 


IEF236I1 
IEF2371 
IEF2371 
IEF2371 
TEF2371 


ALLOC. FOR JOB3 
SYSUT1 ON 190 
SYSLMOD ON 190 
SYSLIB ON 190 
SYSLIN ON 190 


STEP4 . 


{ E-LEVEL LINKAGE EDITOR OPTIONS SPECIFIED--XREF 


3) 


4) { IEWO000 GO NOW ADDED TO DATA SET 


ENTRY 


@ 


CONTROL SECTION 


NAME ORIGIN LENGTH NAME 
TESTRUN 


THDFOISP* 680 


@) 


LOCATION REFERS TO SYMBOL 


00 6AC 


58C 


© 


IN CONTROL SECTION 


> | 


330 


© 


pay ADDRESS 


>) ou 


IHDFDOISP IHDFDISP 


00 


TOTAL LENGTH C3c 


IEF 2851 
- TEF2851 
IEF 2851 
' TEF2851 
IEF 2851 
IEF2851 
IEF 2851 
IEF2851 
IEF 2851 
IEF 2851 


UT1.J0B3 

VOL SER NOS= 
GQJOB 

VOL SER NOS= 
SYS1.COBLIB 
VOL SER NOS= 
SYSOUT 

VOL SER NOS= 
PUNCH 

VOL SER NOS= 


111111. 
111111. 
111111. 
SCRTCH. 
111111. 


Figure 31. Linkage Editor 


CROSS REFERENCE TABLE 


LOCATION 


are automatically generated as output. The 
other forms of output may be requested by 
the PARM parameter in the EXEC statement. 
All output to be listed is written in the 
data set specified by the SYSPRINT DD 
statement. 


Figure 31 is an example of linkage edi- 
tor output listing. It shows the job con- 
trol statements, informative messages, and 
module map. The different types of output 
are numbered and each type to be explained 
is lettered. The text following the figure 
is an explanation of the figure. 


DSNAME=EUT1»,UNIT=SYSDAsSPACE=( TRK+ (100, 10)} 
DSNAME=GOJOB(GO) »,UNIT=SYSDAy SPACE=(TRKy(10071091))5 x 


DSNAME=PUNCH, UNI T=SYSDA,SPACE=(TRK+(100,10)), xX 


NAME LOCATION NAME LOCATION NAME LOCATION 


DELETED 
PASSED 
KEPT 
SYSOUT 


DELETED 


Output Showing Module Map and Cross Reference List 
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The job control statements. These 
statements are listed because 
MSGLEVEL=1 is specified on the JOB 
statement for this job, shown in 


Figure 30. 


Allocation messages from the ‘job 


scheduler. These messages provide 
information about the device alloca- 
tion for the data sets in the job 
step. For example, the message 


IEF2371 SYSUT1 ON 190 


indicates that the data set for SYSUT1 
has been assigned to the device 190. 


Linkage editor informative message. 
This message lists the PARM options 


that were specified. 


Linkage editor informative message. 


This is a disposition message describ- 
ing the disposition of the load 
module. 


A. Name of the load module specified 
in the DSNAME parameter of the 
SYSLMOD DD statement 


Be. Text of message 


Module map. The module map is listed 
when either the XREF or the MAP option 
is specified in linkage editor proc- 
essing. The module map shows all con- 
trol sections in the output module and 
all entry names in each control sec- 
tion. The control sections are 
arranged in ascending order according 
to their assigned origins. All entry 
names are listed below the control 
section in which they are defined. 
Each COBOL program is a control sec- 
tion, and any COBOL library subroutine 
is a separate control section. 


A. Control section. Under this head- 
ing the name, origin, and length 
of each control section is listed. 
Name. The name of the control 
section. This name is the 
PROGRAM-ID name in the main COBOL 
program or a called program. Each 
control section that is obtained 
from a library by an automatic 
library call is indicated by an 
Bes 

Origin. The relative origin in 
hexadecimal notation. 
Length. The number of bytes in 
each control section in hexade- 
cimal notation. 


Be. Entry. The entry names within 
each control section and their 


relative location. A called pro- 
gram may have more than one entry 
point. For a called COBOL program 
name, the entry point is the same 
as the name that is specified by 
the ENTRY statement in the source 
program. 


C. Entry address. The relative 
address of the instruction with 
which processing of the module 
begins. It will always be INIT1 
if the COBOL program is the main 
program of the load module. 


D. Total length. The total number of 
bytes, in hexadecimal notation, of 
the load module. It is the sum of 
the lengths of all control 
sections. 


©) The cross reference list. The cross 
reference list, as well as a module 
map, is listed if the XREF object is 
specified. MAP and XREF should not be 
specified together. The cross 
reference list provides the following 


information: 


A. Location. The relative location 
in the program where another pro- 
gram is called. 


B. Refers to symbol. The name of the 
entry point of the called program. 


C. In control section. The control 
section that contains the entry 
point. 


For example, 328 is the location where 
another program is called. IHDFDISP 
is the entry point of the called pro- 
gram. IHDFDISP is the control section 
that contains the entry point, 
IHDFDISP. 


If XREF is specified, the cross 
reference list appears before the 
Entry Address. 


paheaeiess These massages contain 


information about the disposition of 
the data sets. 


Comments _on_ the Module Map_and_ Cross 
Reference List 


The severity of linkage editor diagnos- 
tics may affect the production of module 
map and cross reference list. 


Since various processing options will 
affect the structure of the load module, 
the text of the module map and cross 
reference list will sometimes provide addi- 
tional information. For example, the load 
module may have an overlay structure. In 
this case, a module map will be listed for 
each segment in the overlay structure. The 
cross reference list is the same as that 
previously discussed, except that segment 
numbers also are listed to indicate the 
segment in which each symbol appears. 


Listing the Linkage Editor Control State- 
ments: If the LIST option | is “specified, 
Tinkage editor control statements, such as 
OVERLAY and LIBRARY, are listed. 


Linkage Editor Messages 


The linkage editor may generate informa- 
tive or diagnostic messages. A complete 
list of these messages is included in the 
publication IBM System/360 Operating System 


Linkage E Editor, Form C28-6538. 


COBOL_LOAD_ MODULE EXECUTION OUTPUT 


The output generated by program execu- 
tion (in addition to data written in pro- 
gram Output files) can include: 


( //STEP5 EXEC PGM=#.STEP4.SYSLMOD 
//SYSOUT DD SYSOUT=A 
(1) //SYSABEND DD SYSOUT=A 

//SAMPLE DD UNIT=2400,LABEL=(,NL) 


-IEF236I ALLOC. FOR JUB3 STEPS 
(2) IEF2371 PGM=*.DD ON 190 

IEF2371 SAMPLE ON 282 

TEF2851 GOJOB 

IFF285I VOL SER NOS= 111111. 

TEF285I SYSOUT 

TEF2851. VOL SER NOS= ; 
@) IFF2851 SYSQUT 

IEF285I VOL SER NOS= 

TEF2851 

TEF2851 VOL SER NOS= LGLOO1. 

TEF2851 GNOJOR 

TEF2851 VOL SER NOS= 111111. 


Figure 32. Execution Job Step Output 


e Data displayed on the console, or on 


the printer 
e Punched data 
e Messages to the operator 
e System informative messages 
e System diagnostic message 


e A system dump 


A dump and system diagnostic messages 
are generated automatically by program 
execution only if the program contains 
errors that cause abnormal termination. 


Figure 32 shows an example of output 
from the execution job step. The following 
text is an explanation of the figure. 


@) The job control statements. These 
statements are listed because 
MSGLEVEL=1 is specified in the JOB 


statement for this job. 


Q) ane The job allocation messages from the 
scheduler These messages indi- 
Sate the device that is allocated for 
each data set defined for the job 
step. 


(3) Disposition messages from the job 


scheduler. These messages are con- 
tained in the publication IBM Systen/ 


360 Operating System: Messages and 
Codes, Form C28-6631. 


PASSED 
SYSQUT 


SYSOUT 


AAANAAAA.AAAAAAAA. AAAAAAAA. AAAAAAAA.ONN00048 DELETED 


DELETED 
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REQUESTS FOR OUTPUT 


The programmer may request output in a 
number of ways: 


1. He can request data to be displayed by 
using the DISPLAY statement. 


2. Messages to the operator can also be 
displayed on the console when 
requested in the source program (DIS- 
PLAY UPON CONSOLE). 


3. The programmer can request a full 
dump, in case his program is ter- 
minated abnormally, by including 


//SYSABEND DD SYSOUT=A 
in the job control procedure. 


Note: Under MVT the SPACE parameter should 
also be included in the DD statement. For 
example: 





//SYSABEND DD SYSOUT=A, X 
, SPACE= (125, (200.1000) RLSE). 


Dumps are explained in the chapter "Program 
Checkout." 


OPERATOR MESSAGES 


The COBOL load module may issue operator 
messages. In the messages, xx denotes a 
system-generated 2-character numeric field, 
which is used to identify the program issu- 
ing the message. 


The following message is generated by 
STOP literal. 
xx IEQOOOA Text is provided by the 
object program. 


Explanation: This message is 
issued at the programmer's 
discretion to indicate poss- 
ible alternative action to be 
taken by the operator. — 


Operator Response: Follow 
the instructions given both 
by the message and on the job 
request form supplied by the 
programmer. If the job is to 
be resumed, issue a REPLY 
command with a text field 
that contains any 1-character 
message. 


The following message is generated by an 
ACCEPT. e««FROM CONSOLE. 
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xx IEQ990D ‘AWAITING REPLY‘ 


Explanation: This message is 
issued by the object program 
when operator intervention is 
required. 


Operator Response: Issue a 
REPLY command. (The contents 


of the text field should be 

supplied by the programmer on 

the job request form.) 
xx IEQ999TI NO DD CARD FOR DDNAME 
Explanation: The operating 
system could not find a 
corresponding ddname on a DD 
statement for a file assigned 
in a SELECT clause. 


Operator Response: User 
should have indicated either 


to continue processing or to 
cancel the job. Note that if 
the user elects to continue 
processing, any READ or WRITE 
encountered for the file will 
result in an ABEND. 


SYSTEM OUTPUT 


Informative and diagnostic messages may 
appear in the listing during execution of 
any job step. Further information about | 
these messages is found in the publication 


IBM System/360 Operating System: Messages 


and Codes, Form C28-6631. 


Each of these messages contains an iden- 
tification code in the first three columns 
of the message to indicate the portion of 
the operating system that generated the 
message. Table 12 lists these codes, along 
with identification for each. 


Table 12. System Message Identification 
Codes 

sears Sata al a ee a 
{Code | Identification | 
o---4-----+---~~-+-~-~-~-----~------+---- 
jIEA | An on-line console message from | 
i | the supervisor. | 
{IEC | An on-line console message from | 
| data management. | 
JIEF | A message from the job scheduler. | 
JIEQ | A message from the COBOL compiler. | 
{IER | A message from the Sort program | 
|IET | A message from the assembler. | 
{IEW | A message from the linkage editor. | 
JIHB | A message from the supervisor and | 
| { data management. | 
ieee iii tee eee ee J 


A programmer using the COBOL (F) compil- 
er under the System/360 Operating System 
has several methods available to him for 
testing his programs, debugging them, and 
revising them for increased efficiency in 
operation. 


The COBOL debugging language can be used 
by itself or in conjunction with other 
COBOL statements. A dump can also be used 
for program checkout. 


THE DEBUG LANGUAGE 


The COBOL (F) debugging language is 
designed to aid the COBOL programmer in 
producing an error-free program in the 
shortest possible time. The sections that 
follow discuss the use of the debug lan- 
guage and other methods of program 
checkout. 


The three debug language statements are 
TRACE, EXHIBIT, and ON. Any one of these 
statements can be used as often as neces- 
Sary. They can be interspersed throughout 
a COBOL source program, or they can be ina 
packet in the input stream to the compiler. 


Program checkout may not be desired 
after testing is completed. A debug packet 
can be removed after testing. This allows 
elimination of the extra object program 
coding generated for the debug statements. 


The output produced by the TRACE and 

EXHIBIT statements is listed on the system 
logical output device (SYSOUT). If these 
statements are used, the SYSOUT DD state- 
ment must be specified in the execution 
time job step. 


The following discussions describe ways 
to use the debug language. 


FOLLOWING THE FLOW OF CONTROL 


The READY TRACE statement causes each 
section and paragraph name to be listed on 
the system output unit when control passes 
to that point. The output appears as a 
list of unqualified procedure-names. 


To reduce the number of names that are 
generated and the time taken to generate 
them, a trace can be stopped with a RESET 
TRACE statement. The READY TRACE/RESET 
TRACE combination is helpful in examining a 
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particular area of the program. The READY 
TRACE statement can be coded so that the 
trace begins before control passes to that 
area. The RESET TRACE statement can be 
coded so that the trace stops when the pro- 
gram has passed the area. The two trace 
statements can be used together where the 
flow of control is difficult to determine, 
@.ge, With a series of PERFORM statements 
or with nested conditionals. 


Another way to control the amount of 
tracing, so that it is done conditionally, 
is to use the ON statement with the TRACE 
statement. When the COBOL compiler encoun- 
ters an ON statement, it sets up a mecha- 
nism such as a counter which is incre- 
mented, during execution, whenever control 
passes through the ON statement. For 
example, if an error occurs when a specific 
record is processed, the ON statement can 
be used to isolate the problem record. The 
statement should be placed where control 
passes only once for each record that is 
read. When the contents of the counter 
equal the number of the record (as speci- 
fied in the ON statement), a trace can be 
taken on that record. The following 
example shows a way in which the 200th 
record could be selected for a TRACE 
statement. 


ae cea aM fete IE vat ete ELE Oa Sea eT Pers 4 
|Col. | 
{1 8 
j----------------------------------------- { 
| RD-REC | 
| . | 
| . | 
i ° | 
| *DEBUG RD-REC TRY | 
1 PARA-NM-1. ON 200 READY TRACE. | 
| ON 201 RESET TRACE. | 
EE ae ag nS ode cP et Ee MOR a Oe eRe ee tte oe Scie ode weet J 


If the TRACE statement were used without 
the ON statement, every record would be 
traced. 


An example of a common program error is 
failing to break a loop or unintentionally 
creating a loop in the program. If many 
iterations of the loop are required before 
it can be determined that there is a pro- 
gram error, the ON statement can be used to 
initiate a trace only after the expected 
number of iterations has been completed. 


Note: If an error occurs in an ON state- 


ment, the diagnostic may refer to the pre- 
vious statement number. 
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DISPLAYING DATA VALUES DURING EXECUTION 


A programmer can display the value of a 
data item during program execution by using 
the EXHIBIT statement. The three forms of 
this statement display (1) the names and 
values of the data-names listed in the 
EXHIBIT statement (EXHIBIT NAMED) whenever 
the statement is encountered during execu- 
tion; (2) the values of the data-names 
listed in this statement only if the value 
has changed since the last execution 
(EXHIBIT CHANGED); and (3) the data-names 
listed in the statement and the value of 
the data-names only if the values have 
changed since the previous execution (EXHI- 
BIT CHANGED NAMED). 


Note: The total length of all items dis- 
played with EXHIBIT CHANGED cannot exceed 
32,767 bytes. 


Data can be used to check the accuracy 
of the program. For example, the pro- 
grammer can display specified fields from 
records, work the calculations himself, and 
compare his calculations with the output 
from his program. The coding for a payroll 
problem could be: 


{Ccol. { 
j1 8 

ga aa a 4 
: 
| : | 
| : l 
| GROSS-PAY-CALC. | 
i COMPUTE GROSS-PAY = j 
| RATE-PER-HOUR * (HRSWKD | 
| + 1.5 * OVERTIMEHRS). ] 
| NET-PAY-CALC. | 
| : l 
| : 
| : l 
| *DEBUG NET-PAY-CALC. l 
l SAMPLE-1. ON 10 AND { 
| EVERY 10 EXHIBIT NAMED | 
| RATE-PER-HOUR, HRSWKD, \ 
| OVERTIMEHRS, GROSS-PAY. | 
tee eke ae oe ee J 


This coding will cause the values of the 
four fields to be listed for every tenth 
data record before net pay calculations are 
made. The output could appear as: 


RATE-PER-HOUR = 4.00 HRSWKD = 40.0 
OVERTIMEHRS = 0.0 GROSS-PAY = 160.00 


RATE-PER-HOUR = 4.10 HRSWKD = 40.0 
OVERTIMEHRS = 1.5 GROSS-PAY = 173.23 


RATE~PER-HOUR = 3.35 HRSWKD = 40.0 
OVERTIMEHRS = 0.0 GROSS-PAY = 134.00 


108 


Note: Decimal points are included in this 
example for clarity, but actual printouts 
depend on the data description in the 
program. 


The preceding is an example of checking 
at regular intervals (every tenth record). 
A check of any unusual conditions can be 
made by using various combinations of COBOL 
Statements in the debug packet. For 
example: 


IF OVERTIMEHRS GREATER THAN 2.0 EX- 
HIBIT NAMED PAYRCDHRS 


In connection with the previous example, 
this statement could cause the entire pay 
record to be displayed whenever an unusual 
condition (overtime exceeding two hours) is 
encountered. 


The EXHIBIT CHANGED statement also can 
be used to monitor conditions that do not 
occur at regular intervals. The values of 
data-names are listed only if the value has 
changed since the last execution of the 
statement. For example, suppose the pro- 
gram calculates postage rates to various 
cities. The flow of the program might be: 








CALCULATE 
RATE FOR 
CITY 











EXHIBIT 
CHANGED 





The EXHIBIT CHANGED statement in the pro- 
gram could be: 


EXHIBIT CHANGED STATE CITY RATE 


The output from the EXHIBIT CHANGED 
statement could appear as: 


01 O01 10 
02 15 
03 
04 10 

02 O1 
02 20 
03 15 
04 

03 O01 10 


The first column contains the code for a 
State, the second column contains the code 
for a city, and the third column contains 
the code for the postage rate. The value 
of a data-name is listed only if it is 
changed since the previous execution. For 
example, since the postage rate to city 02 
and 03 in state 01 are the same, the rate 
is not printed for city 03. 


The EXHIBIT CHANGED NAMED statement 
lists the data-name and the value of that 
data-name if the value has changed. For 
example, the program might calculate the 
cest of various methods of shipping to dif- 
ferent cities. After the calculations are 
nade, the following statement could be in 
the program: 


EXHIBIT CHANGED NAMED STATE CITY RAIL 
BUS TRUCK AIR 


[The output from this statement could appear 
as: 


fl 


STATE = 01 CITY = 01 RAIL = 10 BUS 
14 TRUCK = 12 AIR = 20 


CITY = 02 


03 BUS = 06 AIR = 15 


CITY 


u 


cITyY 04 RAIL = 30 BUS = 25 TRUCK 
28 AIR = 34 


STATE = 02 CITY 01 TRUCK = 25 


CITY 02 TRUCK 20 AIR = 30 


Note that a data-name and its value are 
listed only if the value has changed since 
the previous execution. 


TESTING A PROGRAM SELECTIVELY 


A debug packet allows the programmer to 
select a portion of the program for test- 
ing. The packet can include test data and 
can specify operations the programmer wants 
to be performed. When the testing is com- 
pleted, the packet can be removed. The 
flow of control can be selectively altered 
by the inclusion of debug packets, as 
illustrated in the following example of 
selective testing of B: 


1 Spotter pee a ees 7 
| START | 
| 
t-_-~.—-~--4 
| 
Love a eS ee 1 
Vv 
Gera es Vs ERE S Ses 
| | ! DEBUG | 
| A | | PACKET | 
| | FORA | 
Gee SS d t--__,————J 
| 
fron nnn 4 
| 
V 
oss oe 1 
| | 
| B | 
| | 
L---_,~~~-J 
Ge ee ee Se 1 
| 
V 
aad 1 [Sa 
| | | DEBUG | 
l C l | PACKET | 
l | | FoRC | 
| eee eae ears pee J L_-_-.,-~———4 
| 
| 
[root 4 
| 
Vv 
(Seis oo 1 
| | 
| sToP | 
| RUN | 
eo ee 4 


In this program, A creates data, B proc- 
esses it, and C prints it. The debug pack- 
et for A simulates test data. It is first 
in the program to be executed. In the 
packet, the last statement is GO TO B, 
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which permits A to be bypassed. After B is 
executed with the test data, control passes 
to the debug packet for C, which contains a 
GO TO statement that transfers control to 
the end of the program, bypassing C. 


TESTING CHANGES AND ADDITIONS TO PROGRAMS 


If a program runs correctly but changes 
or additions can make it more efficient, a 
debug packet can be used to test changes 
without modifying the original source 
program. 


If the changes to be incorporated are in 
the middle of a paragraph, the entire para- 
graph, with the changes included, must be 
written in the debug packet. The last 
statement in the packet should be a GO TO 
Statement that transfers control to the 
next: procedure to be executed. 


There are usually several ways to per- 
form an operation. Alternative methods can 
be tested by putting them in debug packets. 


The source program library facility can 
be used for program checkout by placing a 
source program ina library (see 
"Libraries"). Changes or additions to the 
program can be tested by using the BASIS 
card and any number of INSERT and DELETE 
cards. Such changes or additions remain in 
effect only for the duration of the run. 


A debug packet can also be used in con- 
junction with the BASIS card to debug a 
program or to test deletions or additions 
to it. The debug packet is inserted in the 
input stream immediately following the 
BASIS card and any INSERT or DELETE cards. 


DUMPS 


If a serious error occurs during execu- 
tion of a program, the job is abnormally 
terminated; any remaining steps are 
bypassed, and a dump is generated. The 
programmer can use the dump for program 
checkout. (However, any pending transfers 
to an external device may not be completed. 
For example, if a READY TRACE statement is 
in effect when the job is abnormally ter- 
minated, the last procedure-name may not 
appear on the external device.) In cases 
where the abnormal termination does not go 
to completion, a dump is not produced. 

This situation may cause duplicate name 
definition when the next job is run, and is 
discussed at the end of this section. 


If a SYSABEND DD statement has been 


included in the execution-time job step, 
the system will provide the programmer with 
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a printout, in hexadecimal and EBCDIC for- 
mat, Of main storage. Those areas occupied 
by the program, and its data at the time 
the error occurred, will be included. This 
printout is called an abnormal termination 
dump and is identified by the heading *** 
ABDUMP REQUESTED ***, 


If a SYSABEND DD statement is not in- 
cluded in the execution-time job step, or 
its specification has been destroyed, an 
indicative dump is produced. This dump 
does not contain a printout of main 
storage. 


Both dumps include a completion code 
designating the condition that caused the 
termination. The completion code consists 
of a system code and a user code. Only one 
of the codes is nonzero. A nonzero system 
code indicates that the control program 
detected the error. 


A dump cannot be requested in the COBOL 
language. 


The explanation of the system-generated 
completion codes and a complete description 
of the dumps are contained in the publica- 
tion IBM System/360 Operating System: Pro- 
grammer‘’s_ Guide to Debugging, Form 
C28-6670. 


ERRORS THAT CAN CAUSE A DUMP: 


Following is a discussion of some error 
conditions that can cause a program to be 
abnormally terminated and a dump to be 
listed. Input/output errors and errors 
caused by invalid data are discussed. 


Input/Output Errors 


Errors can occur while a COBOL file is 
being processed. For example, an uncor- 
rectable input/output error can occur dur- 
ing data transmission. If the file being 
processed is organized sequentially and no 
error-processing declarative has been 
specified for the file, the job is ter- 
minated. If it is a QSAM file, the job 
will be terminated if no declarative and no 
EROPT option in the DD statement have been 
specified. 


Another error that can cause termination 
is an attempt to read a file whose records 
are larger than those described in the 
source program. The chapter "Additional 
File Processing Information" contains more 
information about input/output errors. 


Errors Caused By Invalid Data 


The abnormal termination of a job may 
result if a data item in invalid format is 
operated on by a statement in the Procedure 
Division. This is particularly true of 
COMPUTATIONAL-3 (internal decimal) and 
numeric DISPLAY (external decimal) items. 


Invalid format may be caused by (1) an 
invalid configuration in the data itself, 
or (2) a data description that does not 
match the data item, which results in 
incorrect processing of the data. Some of 
the program errors that might cause an 
abnormal termination are: 


1. A data item in the Working-Storage 
Section is not initialized before it 
is used, and invalid data is picked 


up. 


2. For an item whose usage is COMPUTA- 
TIONAL, COMPUTATIONAL-1, or 
COMPUTATIONAL-2, either the alignment 
is incorrect, or the description of 
the item does not specify the proper 
alignment. Some examples of when this 
can occur are: 


a. A redefining entry contains one or 
more of the above items and the 
redefined entry is not properly 
aligned. 


b. A record in the Linkage Section of 
a called program is described by an 
01 entry and contains one or more 
of the above items, and the corres- 
ponding argument in the calling 
program is not properly aligned. 


c. A file, containing one or more of 
the above items, is blocked, but 
required interrecord slack bytes 
were not inserted when the file was 
created. If the file is later read 
as an input file, the alignment may 
not be correct. 


3. An input file contains invalid data or 
data incorrectly specified by its data 
description. For example, the con- 
tents of the sign position of an 
internal or external decimal data item 
in the file may be invalid. The com- 
piler does not generate a test to 
check the sign position for a valid 
configuration before the item is used 
as an operand. 


4. No conversion or editing is done in a 
move involving a group item. There- 
fore, if a group item is moved to a 
group item and the subordinate data 
descriptions are incompatible, the new 
data in the receiving field may not 


match the corresponding data 
descriptions. 


5. The SIZE ERROR option is not specified 
for the COMPUTE statement, the results 
of the calculation are larger than the 
specified resultant COMPUTATIONAL 
data-name, and the results are then 
used in subsequent calculations. 


6. The SIZE ERROR option is not specified 
for a DIVIDE statement, and an attempt 
is made to divide by zero. 


7. ‘The USAGE specified for a redefining 
data item is different from the USAGE 
specified for the redefined item, and 
the item is referred to by the wrong 
name for the current content. 


8. If a record contains a data item 

described by an OCCURS clause with the 

data-name data 
items in the record may be affected by 
a change in the value of data-name 
during the course of program execu- 
tion. This may result in incorrectly 
described data. Additional informa- 
tion about how to correct this situa- 
tion is included in the chapter "Pro- 
gramming Techniques." 


9. The data description in the Linkage 
Section of a called program does not 
correctly describe the data defined in 
the calling program. 


Other Errors 


1. No DD statement is included for a file 


described in the source program and an 
attempt is made to open the file. A 
system console message is written; the 
programmer can elect to direct the 
operator to continue processing his 
program, but any READ or WRITE asso- 
ciated with the unlocated file will 
result in an ABEND. (See "Appendix H: 
Compiler Diagnostic Messages" for the 
format of the generated error 
message.) 


2. A file is not opened and execution of 
a READ or WRITE statement for the file 
is attempted, or a MOVE to a record 
area in the file is attempted. 


3. A GO TO statement, with no procedure 
name following it, is not properly 
initialized with an ALTER statement 
before the first execution of the GO 
TO statement. 


4. Reference is made to an item in a file 


after end of data. This includes the 
use of the TERMINATE statement of the 
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Report Writer feature, if the CONTROL 
FOOTING, PAGE FOOTING, or REPORT FOOT- 
ING contain items that are in the file 
(e.g-, SOURCE data-name, where data- 
name refers to an item in the file). 


5. Block size for an F-format file is not 
an integral multiple of the record 
length. 


6. A value specified for ACTUAL KEY is 
beyond the extents of the data set. 


7. When adding records to a BDAM file, 
there is not enough room for a record 
from the track specified to the end of 
the data set (there may be room on 
earlier tracks, but it will not be 
used). 


8. A READ is issued for a data set 
referenced on a DD DUMMY statement. 
The AT END condition is sensed immedi- 
ately and any reference to a record in 
the data set produces unpredictable 
results. 


9. Under MVT, a STOP RUN statement is 
executed before all files are closed. 


In addition to errors that can result in 
an abnormal termination, errors in the 
source program can occur that cause parts 
of the program to be overlaid and the 
corresponding object code instructions to 
become invalid. If an attempt is then made 
to execute one of these instructions, an 
abnormal termination may result. 


Some reasons for this are: the opera- 
tion code of the instruction is invalid, 
the instruction results in a branch to an 
area containing invalid instructions, the 
instruction results in a branch to an area 
outside the program, such as an address 
protected area. 


Some COBOL source program errors that 
can cause this overlaying are: 


1. Using a subscript whose value exceeds 
the maximum specified in the asso- 
ciated OCCURS clause. 

2. Using a data~name as a counter whose 


value exceeds the maximum value valid 
for that counter. 


USING THE ABNORMAL TERMINATION DUMP 


The programmer can determine the cause 
of an abnormal termination with the follow- 
ing material: 


1. The COBOL program object code listing 
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2e A knowledge of the layout of the COBOL 
object module 


3. The full abnormal termination dump in 
conjunction with the linkage editor 
map or cross reference list 


The chapter entitled "Output" contains a 
format description of the linkage editor 
output and of the COBOL object code list- 
ing. Figure 30 in that chapter shows the 
layout of the COBOL program object module. 


Note: The information in this section 
about the use of the abnormal termination 
dump applies only when running under PCP or 
MFT. For information about the abnormal 
termination dumps under MVT, see the publi- 
cation IBM System/360 Operating System: 
Programmer's Guide to Debugging, Form C28- 
6670. Note that under the MVT option no 
indicative dumps are given. 


The abnormal termination dump provides 
the address at which the load module has 
been loaded (load address) and the address 
of the instruction that caused the inter- 
rupt. The programmer computes the load 
module area by adding the load address to 
the load module length, as shown in the 
linkage editor output. It is now possible 
to determine whether the instruction falls 
within the load module. If it does not, 
the interrupt could have resulted from an 
improper branch to a point outside the load 
module or an error occurring in another 
part of the system. 


If the instruction does fall within the 
load module, the programmer now determines 
in which part: the main program, a COBOL 
library subroutine, or a called program. 
The ranges of the various parts are deter- 
mined by adding their relative origins, as 
shown in the linkage editor output, to the 
load address. 


If the instruction occurred in an object 
module generated for a COBOL program, 
(i.e., the main program), the programmer 
can determine whether or not the instruc- 
tion was one of the generated object code 
instructions. He can determine the address 
of the first instruction in the Procedure 
Division (as found in the object code list- 
ing) by adding its relative location to the 
location of the object module (load address 
plus relative origin). If it was one of 
the object code instructions, a similar 
technique can be used to locate the exact 
instruction. If it was not one of these 
instructions, the error has occurred in 
another part of the object module. Control 
possibly went there because of an improper 
branch. 


If the instruction which initiated the 
dump occurred in a COBOL library subrou- 
tine, or if the original program called 
another program and the instruction oc- 
curred in the called program, the instruc- 
tion can be located by a similar technique. 
The linkage editor cross reference list in- 
dicates the locations where the call to the 
program or subroutine in question was made. 


The sample COBOL program and its output 
in Figure 33 illustrates in detail how an 
object code listing, cross reference list, 
and abnormal termination dump can be used 
together. Circled numbers in the example 
refer to the corresponding numbers in the 
text which follows. Note that all values 
are expressed in hexadecimal format. 
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IDENTIFICATION DIVISION. 
PROGRAM-ID. ‘ABEND*. 
REMARKS « 
THIS IS A PROGRAM TO ILLUSTRATE THE ABNORMAL TERMINATION. 
ENVIRONMENT DIVISION. 
CONFIGURATION SECTION. 
SOURCE-COMPUTER. I18M-360 E50- 
OBJECT-COMPUTER. IBM-360 E50. 
DATA DIVISION. 
WORKING-~STORAGE SECTION. 
01 RECORDA. 
02 A PLCTURE S94) VALUE 1234. 
02 B REDEFINES A PICTURE S9(7) COMPUTATIONAL~3. (9) 
PROCEDURE DIVISION. 


COMPUTE B = B + l. 
STOP RUN. 


INTRNL NAME SOURCE NAME BASE DISPL INTRNL NAME DEFINITION 
DNM=1-030 RECORDA BLI=1 000 DNM=1-030 DS OCL4 
DNM=1-049 A BLI=1 000 ONM=1-049 DS 4C 
ONM=1-059 B BLI=1 000 DNM=1-059 DS 4P 


MEMORY MAP 
TGT 


SAVE AREA 
SWITCH CELL 
TALLY CELL 
UNUSED 
ENTRY~SAVE 
UNUSED 

WORKING CELLS 
OVERFLOW CELLS 
TEMPORARY STORAGE CELLS 
TEMPORARY STORAGE-~2 CELLS 
SBL-O CELLS 

BLL CELLS 

BL~I CELLS 
SUBADR-I CELLS 
ONCTL-I CELLS 
PFMCTL-1I CELLS 
PFMSAV-1 CELLS 
VN-I CELLS 
DECBADR=-1 CELLS 
SAVE AREA =2 
SAVE AREA =3 
XSASW-I CELLS 
XSA-I CELLS 
PARAM- CELLS 
RPTSAV AREA 


LITERAL POOL (HEX) 


OO1EO (LIT+0) 1c 


PGT 


OVERFLOW CELLS 
VIRTUAL CELLS 
PROCEDURE NAME CELLS 
GENERATED NAME CELLS 
OCB ADDRESS CELLS 
VNI CELLS 

LITERALS 

DISPLAY LITERALS 


REGISTER ASSIGNMENT 


REG 6 BLI=1 





e Figure 33. COBOL Program with Abnormal Termination Dump (Part 1 of 3) 
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COMPUTE 


SToPe 


Figure 33. 


QOO1E2 
OOO1ES 
OOO1EC 
OOO1FO 
oo0l1F2 
QOO1F4 
0001F8 
OOOLFC 
000200 
000204 
000206 
00020A 
00020E 
000212 
000216 
000218 
00021C 
oooz21e 
000222 
000226 
000228 
00022C 
000000 
ao00002 
000006 
Q00008 
QOO00A 
Q00Q00E 
000010 
000014 
000018 
Qooo1c 
000020 
000024 
000028 
00002C 
000030 
000032 
000036 


ooo1e2 (6) 


FA 
58 


F 


00000228 
00000000 
00000000 
000001E0 
00000048 
O00001E2 
000001F4 
96 121 
O7 FE 
FEFFFFFE 
C1C2C5D5 


000 C 000 
004 
ooc 


008 
004 
054 
048 
048 
004 
190 
ool 
000 


000 
004 
190 


ooc 


006 


034 


C4404040 


START 


® 


* 
000(4:6),000(1+12) DNM=1-59 
13,004(0,13) 
14412,00C(13) 
15,15 

15214 
13,008(0,5) 

5 4004(0,13) 
14,054(0,13) 
048(13),X*29! 
1,9 
048(13),X*20! 
64004(0,0) 
8,190(0,13) 
7,001(0,0) 
1,0 
0,000(0,8) 
O11 
0,000(0,8) 
8,00410,8) 
751 
619060,13) 
15,14 
14,12,00C(13) 
5,13 

15,0 
9915,006(15) 
15,15 
L4CINIT3) 
L4CEXITR) 
L4¢CINITL) 
L40PGT4 
L4(TGT) 
L40START) 
L4CINIT2) 
03401),x*12¢ 
15314 
X'FRFFFFFFFE 
X#C102C5D5C4404040° 
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E~LEVEL LINKAGE EDITGR OPTIGNS SPECIFIED--XREFsLIST 


T—EWOO00 RUN NOW ADDED TO DATA SET 


—--- CROSS REFERENCE TABLE -~-~ 


CONTROL SECTION ENTRY 
NAME GRIGIN LENGTH NAME LOCATION NAME LOCATION 
ABEND 00 22eE G) 
LOCATION REFERS TO SYMBOL IN CONTROL SECTION 
ENTRY AUDRESS 00 
TOTAL LENGTH 22E 


** * ABODUMP REQUESTED * * * 


JOb AbEND STEP GO TIME 003219 DATE 99366 


CGMPLETIGN CODE SYSTEM = O0C7 
PROGRAM INTERKUPTIGN (DATA) AT LOCATION 008202 
INTERRUPT AT 008208 


PSH AT. ENTRY TO ABEND FF15000D 00008208 


JCB 002258 RB 0003FD68 PLE 00000000 DEB OO003FCFC TIOT OOO3ZFF4&C 
MSS 000022E0 PK/FLG 10912408 FLG OOOO00FE LLS 000006009 
FSA 0403FFB8 TCB 00000000 TME 000022F4 


ACTIVE RBS 


USE/EP 00008020 


CMP 800C7000 
JLB 00000000 


NAME LOCATION NAME LOCATION 


TRN 00000000 
JSE 00000000 


PRB 008000 NM RUN »SZ/STAB 004400C0 PSW FF15000D D0008208 Q 000000 WI/LNK 00002258 

SVRB O3FE7TG NM SVC-401C SZ/STAB OO00CDO72 USE/EP 00005828 PSW FFO040933 40005964 Q D103D1 ‘WI/LNK 00008000 
RG O-7 00008060 50008238 a000006C 09002259 000907BA0 OOO3FFRS 00008060 90000000 
RG 8-15 0O00081FC 00008248 00008020 00008020 00008290 OO0OORI6R 00908202 00008214 

SVRb O3FD68 NM SVC-1O05A SZ/STAB OO0O0CDO72 USE/EP 00005828 PSW FFO4000E 0003FCOC Q DAO3DA WT/LNK OOO3FE70 
RG 0-7 QOO000E0 000082A8 00000918 4000582A 00000000 0003F908 00008250 BOOO59CE 
RG 8-15 000022E0 OO00831E 00040000 00002258 00002258 00008288 50005A70 10008202 








Figure 33. 
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COBOL Program with Abnormal Termination Dump (Part 3 of 3) 


The completion code, (4), in the dump 
indicates the condition causing the 
abnormal termination. If the system 
part of the code is nonzero, the 
explanation is found in the publica- 
tion IBM System/360 Operating System: 
Programmer's Guide to Debuggin Form 
C28-6670. In this example, invalid 
data is the reason for termination. 


The INTERRUPT AT hhhhhh entry, (2), 
gives the hexadecimal address of the 
instruction following the instruction 
that initiated the interrupt and 
caused the dump. This address can be 
used to determine the relative loca- 
tion of the instruction in the load 
module (see item 4 below). In the 
example, the address is 8208. 


To determine the main storage area 
occupied by the load module, add the 
total length of the module, in hexa- 
decimal format, to its load address. 
The load address can be obtained from 
the USE/EP entry, , of the first 
ACTIVE RBS (Request Blocks) specifica- 
tion. The last six digits of this 
entry are the address of the entry 
point (INIT1) in the COBOL program. 

In this case, the address is 8020 in 
hexadecimal format. 


The total length of the load module is 
indicated in the TOTAL LENGTH entry, 

, in the linkage editor output (22E, 
in the example). The highest location 
in the load module is: 


8020+22E=824E 


Thus, the range is from 8020 to 824E. 
Since the 8208 address falls within 
this range, the instruction initiating 
the dump must be within the load 


module. 


To determine the relative location 
within the load module of the instruc- 
tion indicated in the INTERRUPT entry, 
subtract the load address from the 
address of the instruction. In the 
example, this becomes: 


8208-8020=1E8 


To determine whether or not the 
instruction occurred in the object 
module generated for the program, com- 
pare its relative location (1E8) with 
the length, » Of the object module. 
If the relative location is greater, 
the instruction occurred within one of 
the COBOL library subroutines and can 
be located by comparing its relative 
location with the relative origin of 
the subroutines. In this example, 1E8 


is less than 22E, so the instruction 
occurred in the object module. 


6. To determine whether or not the 
instruction was one of the object code 
instructions generated as a result of 
a statement in the Procedure Division 
of the source program, compare its 
relative location with the relative 
location of the first generated 
instruction in the Procedure Division, 

- In this example, the relative 
ocation of the instruction is greater 
than that of the first generated 
instruction (1E8>1E2), and so it can 
be found by locating the corresponding 
relative location. The immediately 
preceding object code instruction then 
is the_instruction that initiated the 
dump (7). In this example, it is an 
instruction generated as a result of a 
COMPUTE statement. Checking back to 
the source program listing, the corre- 
sponding statement (3), is located and 
*B* is seen to be the data-name that 
caused the trouble. B is defined at 
as a COMPUTATIONAL-3 or packed 

decimal item, but the value at B is 
there as a result of a VALUE clause 
for A, the item that B redefines. 
This value is in zoned decimal format 
since there is no USAGE clause speci- 
fied. The configuration of A is 
invalid for B and results in an 
interrupt. 


INCOMPLETE ABNORMAL TERMINATION 


If a job is abnormally terminated and 
the abnormal termination process goes to 
completion, the following procedures are 
carried out: 


°e A dump (ABDUMP) is produced by the 
system. 


e The data sets in the job steps are dis- 
posed of as specz ified in the DISP 
parameter (i.e., kept, deleted, etc.). 
This is indicated in the job scheduler 
disposition messages produced for the 
job step. 


e Temporary data sets, including those 
passed from previous job steps, are 
deleted. 


When the abnormal termination process 
does not go to completion, none of these 
procedures will be carried out. Those data 
sets in the job step that were in existence 
previous to the point at which the error 
condition occurred will remain in effect. 
For data sets on direct-access volumes, the 
names will remain tabulated in the Volume 
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Table of Contents (VTOC) of the volume (see 
the chapter “Additional File Processing 
Information" for additional information on 
the vToc). The result is that space needed 
by a subsequent job will be unavailable, 
or, if the same job is then rerun, dupli- 
cate name definitions will result for those 
data sets that are newly created in the job 
step. This is true for temporary data sets 
for which the system has assigned the name, 
as well as data sets for which the pro- 
grammer has assigned the name. 


SCRATCHING DATA SETS 


To avoid duplicate name definition and 
to ensure that space will be available for 
newly created data sets, the programmer can 
scratch his direct-access volume data sets 
by using the utility program IEHPROGM. To 
scratch such a data set means to remove its 
data set label (which includes its name) 
from the VTOC and to make the space 
assigned to it available for reallocation. 
Scratching does not uncatalog any cataloged 
data sets. This is done by the UNCATLG 
option of the IEHPROGM. 


Note: The information in this section 
about scratching data sets applies only 
when running under PCP. Under the MFT and 
MVT options, direct-access volume data sets 
are scratched automatically. For use of 
the system utilities under these options, 


see the publication IBM System/360 Operat- 
ing System: Utilities, Form C28-6586. 


If a DSNAME parameter has been specified 
in the DD statement for the data set, the 
IEHPROGM utility program requires the name 
of the data set. For data sets named by 
the programmer, the specified name is the 
dsname. For data sets for which the 
DSNAME=&name convention has been used, an 
internal name of the format 


jobname. name 


the name of the job and name is in the 
Sname. If no DSNAME parameter was speci- 
fied, an internal name of the format 


AAAAABAA, AAAAAAAA, AAAAAAAA, AAAAAAAA, 
nnnnnnnn 


is assigned by the system, where n denotes 
a digit between 0 and 9. For data sets 
with no DSNAME parameter there exists an 


option by which the programmer can specify 
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that all such data sets on the volume be 
scratched, without having to specify their 
names. 


If the programmer wishes to obtain a 
listing of the names of all the data sets 
on a volume, including system-assigned 
internal names, he can use the utility pro- 
gram IEHLIST. This program provides a 
listing of the vToc of the volume. 


Information on how to use these utility 
programs is contained in the publication 
IBM System/360 Operating System: Utili- 
ties, Form C28-6586. The following example 
illustrates a job control procedure that 
might be used to scratch temporary data 
sets: 


//SCR JOB , SCRATCH, MSGLEVEL=1 
//STEP1 EXEC PGM=IEHPROGM 
//SYSPRINT DD SYSOUT=A 
//DD1 DD UNIT=2311, DISP=OLD 
//DD2 DD UNIT=2311,DISP=OLD, xX 
11 VOLUME=SER=222222 
//SYSIN DD * 
SCRATCH DSNAME=GOJOB.TEMP, X 
fl VOL=2311=222222, PURGE 
SCRATCH VTOC, VOL=2311=222222,X 
11 SYS, PURGE 
/* 


In this example, the SYSPRINT DD state- 
ment specifies the output data set for the 
listing and the DD1 DD statement specifies 
the system residence volume. The other DD 
statements specify the volume serial number 
of the mountable volumes on which the data 
sets have been written. These DD state- 
ments are needed to allocate the required 
devices. The first SCRATCH statement 
scratches a data set for which DSNAME=&TEMP 
had been specified on the DD statement, and 
the second SCRATCH statement scratches all 
data sets on the volume for which no DSNAME 
parameter had been specified. 


Note that the possibility of duplicate 
name definition also applies to cataloged 
procedures in which temporary data sets are 
used. 


For those procedures that are executed 
often, the programmer may wish to include, 
at the beginning of his job, a procedure to 
scratch all temporary data sets. 


This chapter describes some techniques 
for increasing the efficiency of a COBOL 
program. It is organized according to the 
COBOL clause to which the techniques are 
related. The clauses are arranged alpha- 
betically under the division (Data or Pro- 
cedure) to which they belong. 


DATA DIVISION 


The compiler assigns a permanent regis- 
ter to the first 4096-byte area of items 
defined in the Working-Storage Section and 
five registers to the first five data sets 
defined in the File Section. Thus, for 
optimum addressing of storage by the con- 
trol program, the programmer should define 
the most used data items in Working-Storage 
and the most frequently accessed data sets 
first. 


When writing Data Division statements, 
the COBOL programmer need not concern him- 
self with data problems such as decimal- 
point alignment and mixed data formats; the 
compiler generates extra instructions to 
perform the necessary adjustments. 


The Procedure Division operations that 
most often require adjustments include the 
MOVE statement, the IF statement when used 
in a relation test, and the arithmetic 
operations. Extra code can be avoided by 
more efficient use of Data Division 
clauses, such as the OCCURS, REDEFINES, 
PICTURE, and USAGE clauses. 


IpTS: If a subscript is represented 
by a constant, the location of the sub- 
scripted data item within the table or list 
is resolved at compile time. 


If a subscript is represented by a data- 
name, the location is resolved at execution 
time. The location is not recalculated 
when the value of data-name is changed as a 
result of a data transfer to an elementary 
item to which data-name relates by rede- 
finition. The more efficient format, in 
this case, is COMPUTATIONAL, with PICTURE 
size less than five integers. 


PROGRAMMING TECHNIQUES 


THE DEPENDING ON OPTION: If a data item 
described by an OCCURS clause with the 
DEPENDING ON data-name option is followed 
by nonsubordinate data items, a change in 
the value of data-name during the course of 


program execution will have the following 
effects: 


1. The size of any group described by or 
containing the related OCCURS clause 
will reflect the new value of 
data-name. 


2. The location of any nonsubordinate 
items following the item described 
with the OCCURS clause will be 
affected by the new value of data- 
name. If the user wishes to preserve 
the contents of these items, the fol- 
lowing procedure can be used: prior 
to the change in data-name, move all 
nonsubordinate items following the 
variable item to a work area; after 
the change in data-name, move all the 
items back. 


For example, assume that the Data Divi- 
sion of a program contains the following 
coding: 


01 ANYRECORD 
02 A PICTURE S999 COMPUTATIONAL-3. 
02 TABLEA PICTURE S999 OCCURS 100 
TIMES DEPENDING ON A. 
02° GROUPB 
Subordinate data items. 
End of record. 


GROUPB items are not subordinate to TABLEA, 
which is described by the OCCURS clause. 
Assuming that WORKB is a work area with the 
same data structure as GROUPB, the follow- 
ing procedural coding could be used: 


1 MOVE GROUPB TO WORKB 
2 COMPUTE new value of A 
3 MOVE WORKB TO GROUPB 


The above statements can be avoided by put- 
ting the OCCURS...DEPENDING ON clauses at 
the end of the record. 


Note: Data-name can also change because of 
a change in the value of an item that rede- 
fines it. In this case, the group size and 
the location of nonsubordinate items as 
described in the two preceding paragraphs 
are indeterminable. 
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DEPENDING ON Used More Than Once: Problems 
may arise when OCCURS...DEPENDING ON is 
used more than once, or on more than one 
level, in the same logical record. For 
example, in the description of an output 
file, the following two uses of the OCCURS 


clause are valid: 


FD Fi. 
01 R1. 
02 A USAGE non computational. 
02 B USAGE non computational. 
02 G-1. 
03 X OCCURS integer TIMES 
DEPENDING ON A. 
03 Y OCCURS integer TIMES 
DEPENDING ON B. 


and 


FD F2. 
01 R2. 
02 A USAGE non computational. 
02 B USAGE non computational. 
02 G-2. 
03 X OCCURS integer TIMES 
DEPENDING ON A. 
04 Y OCCURS integer TIMES 
DEPENDING ON B. 


The problem arises when either A or B do 
not contain information that is valid for 
their USAGE. If A contains invalid data 
for its usage, then the value of B cannot 
be changed, and vice versa. 


This situation can be avoided by using 
either of the following two methods: 


ae FDece 
01 R1. 
02 DUMMY-GROUP-OF-A-AND-B. 
03 A. 
03 B. 
02 GROUP A. 
03 X OCCURS integer TIMES 
DEPENDING ON A. 
03 Y OCCURS integer TIMES 
DEPENDING ON B. 


WORKING-STORAGE SECTION. 

01 WORKING-STORAGE-GROUP~A-AND-B. 
02 DUMMY-A. 
02 DUMMY-B. 


First, values are moved to DUMMY-A and 
DUMMY-B instead of to A and B as would 
be done ordinarily. Next, WORKING- 
STORAGE-GROUP-A-AND-B is moved to 
DUMMY-GROUP-OF-A-AND-B, and the record 
is properly initialized. 
b. Environment Division: 

APPLY WRITE-ONLY ON F-1. 


Data Division: 
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FD F-1. 
01 RCD-NAME PICTURE X 
(maximum length of record). 


WORKING-STORAGE SECTION. 
01 R-N. 
02 A. 
02 B. 
02 GROUP A. 
03 X OCCURS integer TIMES 
DEPENDING ON A. 
03 Y OCCURS integer TIMES 
DEPENDING ON B. 


The record is described and worked on in 
the Working-Storage Section. Then, with 
the execution of WRITE RCD-NAME FROM R-N, 
the correct result is obtained. 


ditional Considerations Further 
restrictions on the use of the OCCURS... 
DEPENDING ON clause are noted below: 


e When OCCURS...DEPENDING ON is specified 
for one record of a file and data-name 
is in the same record, the relative 
location of data-name in all records 
for that file must contain valid infor- 
mation of the same usage clause and 
size. 


e When more than one record of a file 
contains the OCCURS...DEPENDING ON 
clause, the longest possible record 
must be defined first. 


e When more than one record of an input 
file contains the OCCURS...DEPENDING ON 
clause, or when the record with the 
OCCURS...DEPENDING ON clause is not the 
first record described under the FD 
entry, once a READ statement has been 
executed for the file, the programmer 
must determine whether or not he is 
working on a record other than the 
first record described under the FD 
entry for the file. If it is not the 
first, and if it contains an OCCURS... 
DEPENDING ON clause, the programmer 
must move a data-name controlling the 
OCCURS...DEPENDING ON items to itself 
to initialize the processing of that 
record correctly. For example, if the 
following record is read in and its 
description is not the first one under 
the FD entry: 


01 REC1. 
O02 A, PICTURE S9. 
02 B, PICTURE S9. 
02 GROUP ONE. 
03 R OCCURS integer TIMES 
DEPENDING ON A, 
PICTURE X(20). 
03 S OCCURS integer TIMES 
DEPENDING ON B, 
PICTURE X(20). 


then one of the following statements must 
be executed before processing of the record 
can begin: 


MOVE A TO A. 
MOVE B TO B. 


e When a record in an output file con- 
tains an OCCURS...DEPENDING ON clause, 
following each WRITE the length of all 
variable length groups and the location 
of nonsubordinate data items following 
the OCCURS clause must be recalculated. 
All data-names of the OCCURS... 
DEPENDING ON clause that are defined in 
the File Section are assumed to contain 
the maximum declared value. For those 
data-names that are not defined in the 
File Section the current contents of 
the OCCURS...DEPENDING ON data-name are 
used. For example, if the following 
are Data Division entries for output 
files: 


FILE SECTION. 


01 R1. 
02 A, PICTURE S9(4). 
02 B, OCCURS 5 TIMES DEPENDING 
ON A. 
01 R2. 
02 C, OCCURS 5 TIMES DEPENDING 
ON D. 


WORKING-STORAGE SECTION. 


77 D, PICTURE $9(4). 

when the following code is executed in 
the Procedure Division: 
MOVE 1TOA, De. WRITE R1. WRITE R2. 


B is re-initialized to 5 occurrences 
while C remains at one occurrence. 


e When OCCURS...DEPENDING ON data-name is 
used more than once in the same logical 
record, the different data-names must 
all appear in the same Data Division 
Section. For example, if the multiple 
in a record defined in the File Sec- 
tion, all the data-names must also be 
defined in the File Section. 


REDEFINES Clause 


REUSING DATA AREAS: The main storage area 
can be used more efficiently by writing 
different data descriptions for the same 


data area. For example, the coding that 
follows shows how the same area can be used 
as a work area for the records of several 
input files that are not processed 
concurrently: 


WORKING~STORAGE SECTION. 
01 WORK-AREA-FILE1. 


Largest record description for 
FILE1 


01 WORK-AREA-FILE2 REDEFINES 
WORK-AREA-FILE1. 


Largest record description for 
FILE2 


ALTERNATE GROUPINGS AND DESCRIPTIONS: Pro- 
gram data can be described more efficiently 
by providing alternate groupings or data 
descriptions for the same data. As an 
example of alternate grouping, suppose a 
program makes references both to a field 
and to its subfields where it would be more 
efficient to describe the subfields with 
different usages. This can be done with 
the REDEFINES clause as follows: 


01 PAYROLL-RECORD. 
02 EMPLOYEE-RECORD PICTURE X(28). 


02 EMPLOYEE-FIELD REDEFINES 
EMPLOYEE- RECORD. 


03 NAME PICTURE X(24) 
DISPLAY. 


03 NUMBER PICTURE S9(5) 
COMPUTATIONAL. 


02 DATE-RECORD PICTURE X(10). 


As an example of different data descrip- 
tions specified for the same data, the fol- 
lowing illustrates how a table can be 
initialized: 


03 Al PICTURE S9(9) 
COMPUTATIONAL VALUE IS 
ZEROES. 


03 A2 PICTURE S9(9) 
COMPUTATIONAL VALUE IS 1. 


02 TABLEA REDEFINES VALUE-A PICTURE 
S9(9) COMPUTATIONAL OCCURS 100 
TIMES. 
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PICTURE Clause 


DECIMAL-POINT ALIGNMENT: Procedure Divi- 
sion operations are most efficient when the 
decimal positions of the data items 
involved are aligned. If they are not, the 
compiler generates instructions to align 
the decimal pasitions before any operation 
involving the data items can be executed. 


Assume, for example, that a program con- 
tains the following instructions: 


77 A PICTURE S999V99 
77 B PICTURE S99V9 


ADD A TO B 


Time and internal storage space are saved 
by defining B as: 


77 B PICTURE S99V99 


If it is inefficient to define B dif- 
ferently, a one-time conversion can be 
done, as explained under "Data Format 
Conversion." : 


FIELDS OF UNEQUAL LENGTH: When a data item 
is moved to another data item of a dif- 
ferent length, no adjustment has to be 
made. However, if the items are external 
decimal items, the compiler generates 
instructions to insert zeros in the high- 
order positions of the receiving field, if 
it is the larger. 


This generation of extra instructions 
ean be avoided if the sending field is 
described with a length equal to or greater 
than the receiving field. 


SIGN USAGE: The absence or presence of a 
lus or minus sign in the description of an 
arithmetic field often can affect the effi- 
ciency of a program. The following para- 
graphs discuss some of the considerations. 


Decimal Items: The sign position in an 
internal or external decimal item can 
contain: 


1. A plus or minus sign. If S is speci- 
fied in a PICTURE clause, a plus or 
minus sign is inserted if (a) the item 
is in the Working-Storage Section and 
a VALUE clause has been specified or 
if (b) a value for the item is 
assigned as a result of an arithmetic 
operation during execution of the pro- 
gram. If an external decimal item is 
punched, printed, or displayed, an 
overpunch will appear in the low-order 
digit. In EBCDIC code, the configura- 
tion for low-order zeros is not 
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normally a printable character. Low- 
order digits of positive values will 
be represented by one of the letters A 
through I (digits 1 through 9); low- 
order digits of negative values will 
be represented by one of the letters J 
through R (digits 1 through 9). 


2. A hexadecimal F. If S is not speci- 
fied in the PICTURE clause, an F is 
inserted in the sign position if (a) 
the item is in the Working-Storage 
Section and a VALUE clause has been 
specified or if (b) a value for the 
item is developed by the execution of 
the program. An F is treated as posi- 
tive, but is not an overpunch. 


3. An invalid configuration. If an 
internal or external decimal item con- 
tains an invalid configuration in the 
Sign position, and if the item is 
involved in a Procedure Division 
operation, the program will be 
abnormally terminated. 


Unsigned items, that is, items for which 
no S has been specified, are treated as 
absolute values. The compiler tries to 
ensure that a positive value is present for 
these items. Whenever a value (signed or 
unsigned) is stored in, or moved in an ele- 
mentary move, to an unsigned item, a hexa- 
decimal F is stored in the sign position of 
the unsigned item. For example, if an 
arithmetic operation involves signed 
operands and an unsigned result field, 
compiler-generated code will insert an F in 
the sign position of the result field when 
the result is stored. 


For internal and external decimal items 
used as input, it is the user's responsi- 
bility to ensure that the input data is 
valid. The compiler does not generate a 
test to ensure that the configuration in 
the sign position is valid. 


When a group item is involved in a move, 
the data is moved without regard to the 
level structure of the group items 
involved. The possibility exists that the 
configuration in the sign position of a 
subordinate numeric item may be destroyed. 
Therefore, caution should be exercised in 
moves involving group items with subor- 
dinate numeric fields or with other group 
Operations such as READ or ACCEPT. 


Binary Items: An S must be specified in 
the PICTURE clause of a binary item, since 
a binary item is always treated as a signed 
item. 


USAGE Clause 


DATA FORMATS: As shown in Figure 34, COM- 
PUTATEONAL, COMPUTATIONAL-1, and 
COMPUTATIONAL-2 items have specific boun- 
dary alignment requirements. To ensure 
correct alignment, either the programmer or 
the compiler may have to add slack bytes. 
To avoid having to add the slack bytes, 
items that require double-word alignment 
can be defined first (COMPUTATIONAL-2), 
items that require full-word alignment can 
be defined next (COMPUTATIONAL-1 and COMPU- 
TATIONAL items whose PICTURE is S9(5) 
through S9(18)), and items that require 
half-word alignment are defined last (COM- 
PUTATIONAL items whose PICTURE is S9 
through S9(4)). Slack bytes are fully dis- 
cussed in the publication IBM System/360 


C28-6516. 


DATA FORMAT CONVERSION: Operations involv- 
ing mixed, elementary numeric data formats 
require conversion to a common format. 

This usually means that additional storage 
is used and execution time is increased. 
The code generated must often move data to 
an internal work area, perform any neces- 
sary conversion, and then execute the indi- 
cated operation. Often, too, the result 
may have to be converted in the same way. 


If it is impractical to use the same 
data formats throughout a program, and if 
two data items of different formats are 
frequently used together, a one-time con- 
version can be effected. For example, if A 
is defined as a COMPUTATIONAL item and B as 
a COMPUTATIONAL-3 item, A can be moved to a 
work area that has been defined as 
COMPUTATIONAL-3. This move causes the data 
in A to be converted to a COMPUTATIONAL-3 
format. Whenever A and B are used ina 
Procedure Division operation, the work area 
can be referred to, rather than A. Using 
this technique, the conversion is performed 
only once, instead of being done once for 
each operation. 


Moves to and from group items, without 
the CORRESPONDING option, as well as com- 
parisons involving group items, are done 
without conversion. 


The seven data conversion statements 
below contain information that indicates 
the type of conversions performed on mixed 
elementary data formats by the code 
generated for each statement. 


Numeric DISPLAY to COMPUTATIONAL-3: 


To Move Data: Converts DISPLAY data to 
COMPUTATIONAL-3 data. 


To Compare Data: Converts DISPLAY data 
to COMPUTATIONAL-3 data. 


To Perform Arithmetic Operations: Con- 
verts DISPLAY data to COMPUTATIONAL- 3 


data. 


To Move Data: Converts DISPLAY data to 
COMPUTATIONAL-3 data and then to COMPU- 
TATIONAL data. 


To Compare Data: Converts DISPLAY to 
COMPUTATIONAL or converts both DISPLAY 
and COMPUTATIONAL data to COMPU- 
TATIONAL-3 data. 


Con- 
verts DISPLAY data to COMPUTATIONAL-3 or 
COMPUTATIONAL data. 


COMPUTATIONAL-3 to COMPUTATIONAL: 


To Move Data: Moves COMPUTATIONAL- 3 
data to a work field and then converts 
COMPUTATIONAL-3 data to COMPUTATIONAL 
data. 


To Compare Data: Converts COMPUTATIONAL 
data to COMPUTATIONAL-3 or vice-versa, 
depending on the size of the field. 


(Same 


To Move Data: Converts COMPUTATIONAL 
data to COMPUTATIONAL-3 data in a work 
field, then moves the work field. 


To Compare Data: Converts COMPUTATIONAL 
to COMPUTATIONAL-3 data or vice-versa, 
depending on the size of the field. 
(Same 


To Perform Arithmetic Operations: 
as for a comparison). 


COMPUTATIONAL to Numeric DISPLAY: 


To Move Data: Converts COMPUTATIONAL 
data to COMPUTATIONAL-3 data and then to 
DISPLAY data. 


_Compare Data: Converts DISPLAY to 
COMPUTATIONAL or both COMPUTATIONAL and 
DISPLAY data to COMPUTATIONAL-3 data, 
depending on the size of the field. 


To Perform Arithmetic Operations: De- 
pending on the size of the field, con- 
verts DISPLAY data to COMPUTATIONAL 
data, or both DISPLAY and COMPUTATIONAL 
data to COMPUTATIONAL-3 data, in which 
case the result is generated ina 
COMPUTATIONAL-3 work area and then con- 
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verted and moved to the DISPLAY result 
field. 


COMPUTATIONAL-3 to Numeric DISPLAY: 


To Move Data: Converts COMPUTATIONAL-3 
data to DISPLAY data. 


‘To Compare Data: Converts DISPLAY data 
to COMPUTATIONAL-3 data. DISPLAY data 
to COMPUTATIONAL-3 data. The result is 
generated in a COMPUTATIONAL-3 work area 
and is then converted and moved to the 
DISPLAY result field. 


Numeric DISPLAY to Numeric DISPLAY: 


To_ Perform Arithmetic Operations: Con- 
verts all DISPLAY data to COMPUTATIONAL- 
3 data. The result is generated ina 
COMPUTATIONAL-3 work area and is then 
converted to DISPLAY and moved to the 
DISPLAY result field. 


ee Se ee Se I ee Se ee ee SE SE 


ERIC DISPLAY FIELDS zeros and blanks 
are not inserted in numeric DISPLAY fields 
by the instruction set. When numeric DIS- 
PLAY data is moved, the compiler generates 
instructions that insert any necessary 
zeros or blanks in the DISPLAY fields. 
When numeric DISPLAY data is compared, and 
one field is smaller than the other, the 
compiler generates instructions to move the 
smaller item to a work area where zeros or 
blanks are inserted. 


COMPUTATIONAL FIELDS: COMPUTATIONAL fields 
can be aligned on either a halfword or 
fullword boundary. If an operation 
involves COMPUTATIONAL fields of different 
lengths, the halfword field is automatical- 
ly expanded to a fullword field. There- 
fore, mixed halfword and fullword fields 
require no additional operations. 


COMPUTATIONAL-1 AND COMPUTATIONAL-2 FIELDS: 
If an arithmetic operation involves a mix- 
ture of short-precision and long-precision 
fields, the compiler generates instructions 
to expand the short-precision field to a 
long-precision field before the operation 
is executed. 
COMPUTATIONAL-3 FIELDS: The compiler does 
not have to generate instructions to insert 
high-order zeros for ADD and SUBTRACT sta- 
tements that involve COMPUTATIONAL-3 data. 
The zeros are inserted by the instruction 
set. 
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Data Formats in the Computer 


The following examples illustrate how 
the various COBOL data formats appear in 
the computer in EBCDIC (Extended Binary- 
Coded-Decimal Interchange Code) format. 
More detailed information about these data 


formats appear in IBM System/360 Principles 
of Operation, Form A22-6821. 


Numeric DISPLAY (External Decimal): Sup- 
pose the value of an item is -1234, and the 
PICTURE and USAGE are: 
PICTURE 9999 DISPLAY. 
or 


PICTURE S9999 DISPLAY. 


The item appears in the computer in the 
following forms respectively: 


Hexadecimal F is treated arithmetically as 
plus in the low-order byte. The hexade- 
cimal character D represents a negative 
sign. 


COMPUTATIONAL-3 (internal Decima sup- 
pose the value of an item is +1234, and its 
PICTURE and USAGE are: 
PICTURE 9999 COMPUTATIONAL-3. 
or 


PICTURE S9999 COMPUTATIONAL-3. 


The item appears in the computer in the 
following forms, respectively: 


Hexadecimal F is treated arithmetically as 
plus. The hexadecimal character C repre- 
sents a positive sign. 


a creel tang! seas areata 
| | 

i 

| Type of |Bytes 

| Data |] Required 
}—----~--_4-..-____--_-_-_ 
{DISPLAY |1 per digit 
{| (external] 

{decimal) | 

| 

| | 

| | 

| | 

}-~------- $------------ 
|DISPLAY |1 per char- 


| Cexternal| acter 
]} floating | (except for 
| point) | Vv) 


| COMPUTA- |1 byte per 
| TIONAL-3 |2 digits 
| (internal|plus 1 byte 


jdecimal) |for the low 
| jorder digit 
| | 

| | 

| | 

| | 

| | 

| i 

Fie eee ee ee 5 ee ene er 
|COMPUTA- |2 if 1<N<4 
|TIONAL =| 

J (binary) ]4 if 5<N<9 

| | 

| |8 if 10<N<18 
| Jwhere N is 

| |the number 

| Jof 9s in the 
| | picture 

{ 

| | 

f--------— +----------+-- 
]COMPUTA- [4 (short- 

| TIONAL-1 |precision) 

| (internal | 

jfloating | 

| point) | 

| | 

| | 

}--------- }------------ 


|COMPUTA- |8 (long-pre- 


| TIONAL-2 | cision) 

| (internal| 

|floating | 

| point) | 

Loe eS deeeme te Sees 
Figure 34. Data Format 


Note: Since the low-or 
internal decimal number 
Sign field, an item wit 


der byte of an 
always contains a 
h an odd number of 


5 rane Loe 
| | | Converted 
|Boundary | Jfor Arith- 
{Alignment | [metic Op- 
]Required |Typical Usage ]erations 

fete ed i an aoa oea ane ean eS 
| No | Input from cards, | Yes 

| ]| output to ] 

| | cards, listings| 

| | 

| | | 

| 

| | | 

| | | 

}--------- 4----------------- 4----------- 
| No |Input from cards, | Yes 

| | output to | 

| | cards, listings] 

| 

| | | 

Mosh ree = fa ee 
] No JInput to a report|Sometimes 

| | item |when a 

] | {small 

| jArithmetic fields |COMPUTA- 

| | | TIONAL-3 

| | Jitem is 

| ]Work areas Jused with 

| | Ja small 

| | | COMPUTA- 

| | TIONAL 

| | | item. 

f--------- }-----------------+----------- 
| half-word] Subscripting | Sometimes 

| | {for both 
|full-word|Arithmetic fields|mixed and 

| | | unmixed 

| full-word| | usages 

| | | 

| | | 

| | 

| | | 

| | 

| | | 

}--------- 4----------------- 4----------- 
| full-word|Fractional expo- | No 

| | nentiation | 

| | | 

| | 

| | | 

| | | 

I 

--------- t------------ ~----}----------- 
|double- |Fractional expo- | No 

| word ] nentiation when] 

| } more precision | 

l | is required | 

| | | 

Poses eS iar eee a Is lca 
Characteristics 


digits can be sto 
an item with ane 
Note that a leadi 
above example. 
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| 
fields up to 18 digits| 


long. 


Fields over 15 digits 
require extra in- 
structions if used in 
computations. 

Converted to internal 
floating point long 
precision format via 
COBOL library sub- 
routine. 

Requires less space than 
DISPLAY. 


Convenient form for 
decimal alignment. 


‘Can be used in 
arithmetic computa- 
tions without 
conversion. 


Rounding and ON SIZE 
ERROR tests are cum- 
bersome if calculated 
result is greater than 
9(9). 


Always must be signed. 


Fields of over 9 digits 
require more handling. 

Tends to produce less 
accuracy if more than 
17 significant digits 
are required and if 
the exponent is big. 
Requires floating- 
point feature. 


me a cr cr cr rr ce re ree ae ee a et eee cere cee ee ne ee 


red more efficiently than 
ven number of digits. 
ng zero is inserted in the 
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COMPUTATIONAL (Binary): Suppose the value 
of an item is 1234, and its PICTURE and 


USAGE are: 
PICTURE S9999 COMPUTATIONAL. 


The item appears in the computer in the 
following form: 


[0,000 | otee | 1101 | 0010 j 

eS Coca Okan! enema en ese i eee a J 
Sign 
Position 


A 0-bit in the sign position means the 
number is positive. Negative numbers are 
represented in two's complement form; thus, 
the sign position of a negative number will 
always contain a 1-bit. 


For example -1234 would appear as 
follows: 


{1} 111] 1011] 0010 {| 1110 | 

ba dee Be oe Eee nonaee J 
Sign 
Position 


Binary Item Manipulation: A binary item is 
allocated storage ranging from one halfword 


to two words, depending on the number of 9s 
in its PICTURE. Figure 35 is an illustra- 
tion of how the compiler allocates this 
storage. Note that it is possible for a 
value larger than that implied by the PIC- 
TURE to, be stored in the item. For 
example, PICTURE S9(4) implies a maximum 
value of 9,999, although it could actually 
hold 32,767. 


Since, in most cases, a binary item is 
manipulated with respect to the actual 
storage capacity allotted to it, the pro- 
grammer can ignore this situation. In the 
following cases, however, he must be care- 
ful of his data: 


1. When the ON SIZE ERROR option is used, 
the size test is made on the basis of 
the maximum value allowed by its PIC- 
TURE, although the result field is 
left unchanged. When no ON SIZE ERROR 
option is used, however, the result of 
a computation could exceed the actual 
capacity of the field in which it is 
stored. Subsequent computations would 
then be made with erroneous data. 


2. When a binary item is displayed or 
exhibited, the value used is a func- 
tion of the number of 9s in the 
picture. 
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3. When the actual value of a positive 
number is significantly larger than 
its picture value, a 1 could result in 
the sign position of the item, causing 
the item to be treated as a negative 
number in subsequent operations. 


Figure 36 illustrates four cases per- 
taining to an item described as PICTURE S9 
COMPUTATIONAL and having an initial value 
of zero. One halfword of storage has been 
allocated, and no ON SIZE ERROR option is 
involved. Note that if the ON SIZE ERROR 
option had been specified, it would have 
been executed for cases B, C, and D. The 
final value would remain as it was initial- 
ly, ise., zero. 


COMPUTATIONAL-1 or COMPUTATIONAL-2 (Float- 


—oOoO————Oeeo OOOO Oe een nnn en eee ee ee ee eee eee eee eee 


ing Point): Suppose the value of an item 
is +1234, and its USAGE is COMPUTATIONAIL-1, 


the item appears in the computer in the 
following form: 


eee acetat eeciehed 1101 0010 0000 0000 eee 


S is the sign position of the number. 


A 0O-bit in the sign position indicates 
that the sign is plus. 


A 11-bit in the sign position indicates 
that the sign is minus. 


This form of data is referred to as 
floating-point. The example illustrates 
short-precision floating-point data. In 
long-precision, the fraction (character- 
istic, mantissa, exponent, etc.) length is 
56 bits. (For a detailed explanation of 
floating-point representation, refer to IBM 
System/360 Principles of Operation, Form 
A22-6821.) 


PROCEDURE DIVISION 


A program can often be made more effi- 
cient in the Procedure Division with some 
of the techniques described below. 


Intermediate Results 


The compiler treats arithmetic state- 
ments aS a succession of operations and 
sets up intermediate result fields to con- 
tain the results of these operations. 
Examples of such statements are the COMPUTE 
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[ PICTURE { Maximum Working value 

[S9 through s9(4) ma rns 
5045) through s9(9) 2,147,483, 647 
Nesta) through $9(18) | 9, 223,372,036, 854, 775, 807 
Pigaea Ges “Hemet icnenipcor PicTUne © Gicsage Bilocetion 


[soo De ee ee En ep Ee ee ge a oN ee Pe ge ely ree oe a oi eee 1 
| ] Actual Hexa- | Decimal | Hexadecimal Value in Decimal Value in \Display or | 
] Case | Decimal Value | Value | Allocated Storage ] Allocated Storage|Exhibit Value | 
j~----- }--------------- }-------- 4-------------~------- }------------------ 4$-------------- { 
] A | 0000 0008 | +8 0008 | +8 | 8 | 
| | | | | | | 
| B | 0000 000A | +10] 000A | +10 | 0 | 
| | | | | | 
Jc | 0000 ¢c350 {| +50000} C350 { -15536 ] 6 | 
| | | | | | 
| D | 0001 0001 | +32769} 0001 | +1 | 1 | 
bbetoac ye Oa ee a a Reema ne (arpa merce toe ve Py emt ace ee vera 6 [aap ae Ecc ane re SC Pie ee J 
Figure 36. Treatment of Varying Values in a Data Item of PICTURE S9 

statement, arithmetic verbs, and statements length of the divisor plus the length of 


containing arithmetic expressions. Appen- 
dix. E in the publication IBM System/360 
Operating System: COBOL Language, Form 
C28-6516 describes the algorithms used by 
the compiler to determine the number of 
places reserved for intermediate result 
fields. 


Intermediate Results and Binary Data Items: 
If an operation involving binary operands 
requires an intermediate result greater 
than 18 digits, the compiler converts the 
operands to internal decimal before per- 
forming the operation. If the result field 
is binary, the result will be converted 
from internal decimal to binary. 


If an intermediate result will not be 
greater than nine digits, the operation is 
performed most efficiently as binary data 
fields. 


Intermediate Results and COBOL Library Sub- 


routines: If a decimal multiplication 
operation requires an intermediate result 
greater than 30 digits, a COBOL library 
subroutine is used to perform the multipli- 
cation. The result of this multiplication 
is then truncated to 30 digits. 


A COBOL library subroutine is used to 
perform division if (1) the divisor is 
equal to or greater than 15 digits, (2) the 


the dividend is greater than 16 bytes, or 
(3) the scaled dividend is greater than 30 
digits (a scaled dividend is a number that 
has been multiplied by a power of ten in 
order to obtain the desired number of 


' decimal places in the quotient). 


Tne Meds see tesa es Create ee 30 
Digits: Whenever the number of digits ina 
decimal intermediate result field is great- 
er than 30, the field is truncated to 30 
digits. A warning message will be 
generated at compilation time, but program 
flow will not be interrupted at execution 
time. This truncation may cause a result 
to be invalid. 


If the possibility exists that an inter- 
mediate result field may exceed 30 digits, 
truncation can be avoided by the specifica- 
tion of floating-point operands 
(COMPUTATIONAL-1 or COMPUTATIONAL-2) ; 
however, accuracy may not be maintained. 


Intermediate Results and Floating-Point 


Data Items: If an Operation that results 
in a floating-point intermediate result 
field involves an exponent overflow, the 
job will be abnormally terminated. (If the 
binary or internal decimal data is in 
accord with its data description, no inter- 
rupt can occur because of an overflow con- 
dition in an intermediate result. This is 
due to the truncation described in the pre- 
ceding paragraph.) 
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Intermediate Results and the ON SIZE ERROR 
Option: The ON SIZE ERROR option applies 
only to final calculated results and not to 


intermediate result fields. 


MOVE Statement 


Performing a MOVE for an item greater 
than 256 bytes in length requires the 
generation of more instructions than are 
required for a MOVE of an item of 256 bytes 
or less. 


OPEN and CLOSE Statements 


There are two ways to open or close sev- 
eral files. For example, with OPEN they 
are: 
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OPEN INPUT file-name-A file-name-B 


file-name-c 


and 


OPEN INPUT file-name-A 
OPEN INPUT file-name-B 
OPEN INPUT file-name-C 


Each opening or closing of a file requires 
the use of main-storage area that is 
directly proportional to the number of 
files being opened. Opening or closing 
more than one file with the same statement 
is faster than using a separate statement 
for each file. Separate statements, howev- 
er, require less storage. 


If an output file has not been closed 
when a STOP statement is encountered, the 
operating system will write the current 
contents of the buffers prior to closing 
the file. As a result, extraneous data may 
be placed on the output file. 


The Report Writer feature permits the 
programmer to specify the format of a 
printed report. In the Data Division, the 
programmer describes once only the names 
and formats of the reports he wants pro- 
duced. In the Procedure Division he writes 
the statements that generate the reports. 
Detailed information on using the Report 
Writer feature can be found in the publica- 
tion IBM System/360_ Operating System: _ 
COBOL Language, Form C28-6516. 


SS ee ee 


RECORD LENGTH AND FORMAT 


The length of a report output record is 
always 144 characters. The RECORD CONTAINS 
clause of the File Description entry asso- 
ciated with the report is implicitly over- 
ridden by the COLUMN clause in the Report 
Section of the Data Division, and, there- 
fore, does not determine the length of a 
report record. 


The format of a report output record 
(i.e., the RECORDING MODE), if not speci- 
fied, will be determined by the compiler. 


USING CONTROL ITEMS IN CONTROL FOOTINGS 


When control names are used as informa- 
tion to be displayed after control breaks, 
the programmer should remember that it is 
the change in a control name that brings 
about a break. The control name displayed 
in the heading or footing may therefore be 
incorrect. 


For example, the programmer might be 
using the SOURCE clause to print COST FOR 
JANUARY $X.XX as a footing when the end of 
the January records has been reached. 
However, the end of the January records 
occurs when the control name (MONTH) 
changes to FEBRUARY, and the footing is 
thus put out as COST FOR FEBRUARY $X. XxX. 
This situation can be avoided by saving the 
control name in a temporary area. 


SUMMING TECHNIQUE 


The object program can be made more 
efficient with respect to execution time by 
keeping in mind the fact that Report Writer 


USING THE REPORT WRITER FEATURE 


source coding is treated as though the pro- 
grammer had written the program in COBOL 
without the Report Writer feature. There- 
fore, a complex source statement or series 
of statements will generally be executed 
faster than simple statements which perform 
the same function. The example below shows 
two coding techniques for the Report Sec- 
tion of the Data Division. Method 2 uses 
the more complex statements. 


RDeeeeeCONTROLS ARE YEAR MONTH WEEK DAY. 


Method 1: 01 TYPE CONTROL FOOTING YEAR. 
02 SUM COST. 
01 TYPE CONTROL FOOTING MONTH. 
02 SUM COST. 
01 TYPE CONTROL FOOTING WEEK. 
02 SUM COST. 
01 TYPE CONTROL FOOTING DAY. 
02 SUM COST. 


Method 2: 01 TYPE CONTROL FOOTING YEAR. 

02 SUM A. 

01 TYPE CONTROL FOOTING MONTH. 
02 A SUM B. 

01 TYPE CONTROL FOOTING WEEK. 
02 B SUM C. 

01 TYPE CONTROL FOOTING DAY. 
02 C SUM COST. 


Method 2 will execute faster. One addition 
will be performed for each day, one more 
for each week, and one for each month. In 
Method 1, four additions will be performed 
for each day. 


LEVELS 


The compiler expects only levels 01 and 
02 in Report Group descriptions, that is, a 
group entry followed by elementary entries. 
The 01 entry must contain a TYPE clause and 
may contain a LINE and a NEXTGROUP clause. 
Level numbers higher than 02 should not be 
used. The 02 entries must contain a 
SOURCE, VALUE, or a SUM clause and must not 
contain a TYPE or a NEXTGROUP clause. 


TALLY 


TALLY may be used as the operand of 
SOURCE and SUM clauses. 
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{ OUTPUT LINE OVERLAY 


The Report Writer output line is put 
together by the use of an internal rede- 
fines specification indexed by the integer 
that specifies the column. There is no 
check to prevent overlay on any line. In 
the following example, 


02 COLUMN 10 PICTURE X(20) VALUE 
OMX 66262 <e 


02 COLUMN 12 PICTURE X(5) VALUE, 
etc. 


the length of 20 beginning in column 10 
followed by a specification for column 12 
could cause field overlay. 


LINE-COUNTER 


Line and page counters may be referred 
to in the Procedure Division. The 
generated program relies entirely on the 
value of LINE-COUNTER to maintain correct 
alignment. Therefore, if the programmer 
references LINE-COUNTER using its value, 
and not changing it, he need not keep track 
of his alignment. 


PAGE BREAKS 


The Report Writer page break routine 
operates independently of the routines that 
are executed after any control breaks 
(except that a page break will occur as the 
result of a NEXT GROUP NEXT PAGE or LINE 
NEXT PAGE clause). Thus, the programmer 
should be aware of the following facts: 


1. A Control Heading is not printed after 


a Page Heading except as a result of 
the first GENERATE statement. If the 
programmer wishes to have the equiva- 
lent of a Control Heading at the top 
of each page, he must include the 
information and data to be printed as 
part of the Page Heading. But since 
only one Page Heading may be specified 
for each report, he should be selec- 
tive in considering his Control Head- 
ing because this Control Heading will 
be the same for each page, and may be 
printed at inopportune times (see 
"Control Footings and Page Format" in 
this chapter). 


2. GROUP INDICATE items are not printed 
after page breaks unless a break has 
also occurred for the control item 
governing the GROUP INDICATE clause. 
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WITH CODE CLAUSE 


When more than one report is being writ- 
ten on a file and the reports are to be 
selectively written, a unique i-character 
code must be given for each report. (A 
mnemonic-name is specified in the RD-level 
entry for each report and is associated 
with the code in the Special-Names para- 
graph of the Environment Division.) This 
code will be written as the first character 
of each 144-character record that is writ- 
ten on the file. If the code character is 
omitted, reports cannot be selectively 
printed. 


When the programmer wishes to write a 
report from this file, he needs merely to 
read a record, check the first character 
for the desired code, and have it printed 
if the desired code is found. The record 
will be printed starting from the third 


character, as is seen here: 

ities sa epiencnss aera Me ee ee 1 

| | CONTROL | | 

\CODE| | RECORD | 

| | CHAR. | 

toed oe Lee eo ea ge Me Na eee ee J 
1 1 142 


The WRITE AFTER ADVANCING (CONTROL | CHAR) 
LINES feature must be used. 


CONTROL FOOTINGS AND PAGE FORMAT 


Depending on the number and size of Con- 
trol Footings (as well as the page depth of 
the report), all of the specified Control 
Footings may not be printed on the same 
page if a control break occurs for a high- 
level control. When a page condition is 
detected before all required Control Foot- 
ings are printed, the Report Writer will 
print the Page Footing (if specified), skip 
to the next page, print the Page Heading 
(if specified) and then continue to print 
Control Footings. 


If the programmer wishes all of his Con- 
trol Footings: to be printed on the same 
page, he must format his page in the RD- 
level entry for the report (by setting the 
LAST DETAIL integer to a sufficiently low 
line number) to allow for the necessary 
space. 


In order to use the System/360 Operating 
System Sort/Merge program, Sort Feature 
statements are written in the COBOL source 
program. These statements are described in 
the publication IBM System/360_ Operating 
System: COBOL Language, Form C28-6516. 


The Sort/Merge program itself is described 
in the publication IBM System/360 Operating 
System: Sort/Merge Program, Form C28-6543. 
The chapter "Machine Considerations" in 
this publication contains information about 
system requirements when the Sort Feature 
is used. 


DD statements must. be written in the 
execution-time job steps of the procedure 
to describe the data sets used by the sort 
program. DD statements for data sets used 
during the sort process are described in 
the section "Sort DD Statements." 


Note: The SORT/MERGE CHECKPOINT/RESTART 
feature is not available to the programmer 
who uses the COBOL SORT statement. 


SORT DD STATEMENTS 


Three types of data sets can be defined 
for the sort program in the execution time 
job step: input, output, and work. In 
addition, data sets must be defined for the 
use of the system during the sorting 
- operation. 


SORT INPUT DD STATEMENTS 


When the USING option is specified in 
the SORT statement, the input data set must 
be associated with the ddname SORTIN. This 
name must appear as the external name in an 
ASSIGN clause in the COBOL source program. 


When INPUT PROCEDURE is specified, a 
SORTIN DD statement is not required. 


SORT OUTPUT DD STATEMENTS 


When the GIVING option is specified in 
the SORT statement, the output data set 
must be associated with the ddname SORTOUT. 
This name usually appears as the external 
name in an ASSIGN clause in the COBOL 
source program, except in the special case 


USING THE SORT FEATURE 


where both USING and GIVING options are 
used and both refer to the same file-name. 
In this case, the external-name in the 
ASSIGN clause will be ‘SORTIN'. See the 
section entitled "Sharing Devices Between 
Tape Data Sets" later in this chapter. 


When the OUTPUT PROCEDURE option is 
specified, a SORTOUT DD statement is not 
required. 


File Processing Technique for SORTIN and 
SORTOUT 


When either SORTIN or SORTOUT is speci- 
fied, the QSAM file processing technique 
must be used. QSAM is discussed in the 
chapter "User-Defined Files" and in the 


publication IBM System/360 Operating Sys- 
tem: COBOL Language, Form C28-6516. 


SORT WORK DD STATEMENTS 


The sort program requires at least three 
work data sets. The ddname for each DD 
statement is in the form SORTWKnn, where nn 
is a decimal number. The ddnames for the 
required data sets must be SORTWK01, 
SORTWK0O2, and SORTWKO3. Up to 29 other 
work data sets may be defined, but their 
ddnames must be consecutively numbered, 
beginning with 04. 


SORTWKnn Data Set Considerations 


Intermediate data sets (i.e., SORTWKnn 
data sets) for a sort may be assigned to 
either magnetic tape or direct-access 
devices. All of the intermediate storage 
for one sort must be assigned to the same 
device type. It may not be on both 7-track 
tape and 9-track tape units in the same 
sort. Any one of the following devices may 
be used as intermediate storage for a sort: 


IBM 2400-series Magnetic Tape Unit 
(7-track) 

IBM 2400-series Magnetic Tape Unit 
(9-track) 

IBM 2311 Disk Storage Drive 

IBM 2301 Drum Storage 
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The publication IBM System/360 Operating 
System: Sort/Merge Program, Form C28~6543, 


contains more detailed information about 
these devices. 


When the COBOL program is not performing 
the sort operation, the space assigned to 
an intermediate data set may be used for a 
data set not involved in the Sort. For 
example, assume that in a program, an out- 
put data set is created after a sort opera- 
tion is completed. That output data set 
can be assigned to the space that was used 
by a sort intermediate data set. Before 
the space assigned to an intermediate data 
set is reused, an OPEN statement must be 
issued to make the space available. 


The same applies to an input data set 
not involved in the sort. Suppose a data 
set, DSA, is read at some point in the pro- 
gram before the sort takes place, and DSA 
is not to be used again. The space can 
later be made available for one of the 
intermediate sort data sets as long as it 
meets the space requirements for these data 
sets. After DSA is read, a CLOSE statement 
must be issued so that the space will be 
available for the sort operation. Note 
that if a data set is reused, the informa- 
tion for the first use is destroyed. 


Two of the ways to reassign intermediate 
data set space are as follows: 


1. An FD entry can be used in the COBOL 
source program to describe the charac- 
teristics of the data set that is not 
involved in the sort. An ASSIGN 
clause must be specified with the 
appropriate SORTWKnn ddname as an 
external name. 


2. An extra DD statement is used with a 
ddname that is the external name in 
the ASSIGN clause. The UNIT parameter 
in one of the DD statements (usually 
the SORTWKnn statement) should specify 
an affinity to the other DD statement 
in the UNIT parameter, as follows: 


UNIT=AFF=ddname 


The AFF.subparameter causes the system 
to assign to the data set the same 
unit occupied by the data.set speci- 
fied in the named DD statement, which 
must be in the same job step. For 
example, the source statement 


«ASSIGN TO ‘PAYROLL'.... 


might be associated with the following 
DD statements: 


// PAYROLL 
//SORTWKO 2 


DD UNIT=AFF=PAYROLL... 
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This method can be used only to reassign 
intermediate data set space on tape. 


DD STATEMENT REQUIREMENTS FOR SORT DATA 
SETS 


The Sort Feature requires that certain 
parameters be included in the DD statements 
that define data sets used by the program. 
These parameters are summarized in Table 
13. 


Table 14 is a summary of the DCB sub- 
parameters that are required by the sort 
program if the DCB parameter is used. The 
information specified in the DCB sub- 
parameter should not contradict what is 
specified in the COBOL program. 


The DCB subparameters are DEN, TRTCH, 
RECFM, LRECL, and BLKSIZE. The DEN and 
TRTICH subparameters are explained in the 
section "Processing with QSAM" in "User 
Defined Files." 


The format of the RECFM subparameter is 
as follows: 


RECFM= jFB 
VB 


F; Fixed-length records 
V: Variable-length records 
B: Blocked records 


Note that B must be included in the RECFM 
subparameter even if no BLOCK CONTAINS 
clause is specified. In such a situation, 
records are considered to have a blocking 
factor of one. 


For a format V record, add four bytes 
for the control field to the maximum record 
length. For format F, logical record 
length = size of record. 


The BLKSIZE is determined as follows: 


Block Clause Format 
RECORDS F 


Option 


RECFM BLKSIZE Value 
FB integer * 
record length 


FB integer CHARACTERS F 


option 
VB (integer * RECORDS V 
max record option 
length) + (4* 
integer) + 4 
VB integer + 4 CHARACTERS V 
option 


Table 13. Summary of DD Statement Parameters Required by the Sort Feature 


(Spe ae SR a te a ee Rise ee eee © A iarigit earn caasrayt esininaal 1 
| I | JIf Parameter | 
]Parameter]|]Condition under Which Required |Summary of Parameter Value | Omitted | 
~---~----}~-------------------~~---~~------}------=-----------------=--- $~-------------4 
|] DSNAME {The DD statement defines a {Specifies fully qualified | System assigns | 
| labeled input data set (e.g., | name or temporary name of | a unique | 
] | SORTIN), or the data set being | the data set. | | 
] j created is to be kept or | | | 
| | cataloged (e.g., SORTOUT). | | | 
}---~----- }--------------------------------- 4---------------------------- +-------------- { 
] DCB ]The data set is used as the input|Specifies information re- | ---- | 
] | or output data set (SORTIN or | quired by the SORT/MERGE | | 
l | SORTOUT). ] program. | | 
}--------- }-------------------+------------- }----~----------------------- }-------------- { 
] UNIT |The input data set is neither |Specifies (symbolically or |] ---- | 
] | cataloged nor passed, or the | actually) type and quan- | | 
] | data set is being created. | tity of I/O units required| | 
} | | by the data set. | | 
}--------- --------------------------------- 4~--------------------------- t-------------- 1 
| SPACE |The DD statement defines a |Specifies amount of space | micas | 
| | direct-access data set, and the] needed to contain the data| | 
| | data set is being created. | set. | | 
f——-~~---— t-—----~---------------- == === ----- +---------------------------- }-------------- { 
] VOLUME {The input data set is neither |Specifies information used | a | 
‘| | cataloged nor passed, or the | to identify the volume or | | 
| } output data set is on direct | volumes occupied by the | | 
| ] access and is to be kept or | data set. | | 
| ] cataloged. | | | 
}--------~ }--------------------------------- }---------------------------- }-------------- { 
| LABEL |The default value is not appli- ]|Specifies information about |System assumes | 
| | cable. } labeling and retention for| standard | 
| | ] the data set. |] labeling. | 
|~-------- }-------~------------------------- }-------------------~--------4-------------- { 
| DISP {The default value is not appli- |Indicates status and dispo- |System assumes | 
| | cable. | sition of the data set. { anew data | 
| | | | set and | 
| | | | deletes it | 
| | | | after job | 
| | | | step ends. | 
| Se een ce ais Ne en ei de ee ee ee eo Uinta eee ee J 
» Table 14. Summary of DCB Subparameters Required by the Sort Feature 

la ess a ca a a a a ar ee . 
i Subparameter| condition Under Which Required | Summary of Subparameter Value | 
}-----~------ ee { 
| DEN |The data set is located on a |Specifies density at which the tape is | 
] {| 2400-series tape unit, and | recorded. | 
| ] ais recorded in 7~-track | 
| ] format. | | 
}~----------- }------------------------------ t----~-------------------------------------- { 
| TRTCH |The data set is located on a_ |Specifies technique used to record 8-bit | 
| } 2400-series tape unit, and | bytes on a 7-track tape. | 
J | ais recorded in 7-track | | 
| | format. | | 
pom =~ }-------------------------—--=-} --~----- === = 5-5 -- === { 
| RECFM |The DCB parameter is required. |Specifies format of records in the data | 
| | | set. FB or VB is required. { 
}------------ }--~----------------~--------=-}-~-----------------------------------=----- { 
| LRECL |The DCB parameter is required. |Specifies maximum length (in bytes) of | 
| |LRECL is optional. | logical records in the data set. | 
}~----------- $------------------------------ }------------~------------------------------ { 
| BLKSIZE |The DCB parameter is required. |Specifies maximum length (in bytes) of | 
| ] | physical records in the data set. | 
Eis See eS oh a ted ae i a ee ae ye ey i aso aye alee aera en, J 
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SORTIN DD Statement 


For a sort, the SORTIN data set may be a 
previously created data set that may be 
cataloged or uncataloged. The SORTIN data 
set can be on 7-track tape when SORTWKnn 
data sets are on 9-track tape. The follow- 
ing example shows DD statement parameters 
that could be used to define a previously 
created and cataloged input data set: 


//SORTIN DD  DSNAME=INPT, X 
11 DISP=(OLD, DELETE), X 
Ml DCB=(RECFM=FB, x 
1/ BLKSIZE=800, LRECL=80) 


These parameters cause the system to search 
the catalog for a data set named INPT 
(DSNAME parameter). When found, the data 
set is associated with the ddname SORTIN 
and used by the sort program. The control 
program obtains the unit assignment and 
volume serial number from the catalog, and 
displays a mounting message to the opera- 
tor. The DISP parameter indicates that the 
data set has already been created (OLD). 

It also indicates that the data set should 
be deleted (DELETE) after the current job 
step. The DCB parameter indicates that the 
data set contains fixed-length blocked 
records (RECFM) with a physical block 
length of 800 bytes (BLKSIZE) and a logical 
record length of 80 bytes (LRECL). 


SORTOUT DD Statment 


The SORTOUT DD statement must define all 
of the characteristics of the output data 
set. The following example shows DD state- 
ment parameters that could be used to 
characterize an output data set: 


//SORTOUT DD DSNAME=OUTPT,UNIT=2400, xX 
1 DISP=(NEW, CATLG), x 
A DCB=(RECFM=FB, x 
Vf LRECL=90, BLKSIZE=900) 


The DISP parameter indicates that the data 
set is unknown to the operating system 
(NEW) and that it should be cataloged 
(CATLG) under the name OUTPT (DSNAME 
parameter). The UNIT parameter specifies 
that the data set is on a 2400-series tape 
unit. The DCB parameter specifies a fixed- 
length blocked data set (RECFM) with a log- 
ical record length of 90 bytes (LRECL) and 
a physical block size of 900 bytes 
(BLKSIZE). The 9-track format is assumed. 
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SORTWKnn DD Statements 


SORTWKnn data sets may be contained in 
tape or direct-access volumes. When 
direct-access space is assigned, only the 
primary allocation is used by the sort rou- 
tine, and it must be contiguous. 


SORTWKnn data sets: 


1. May not be on 7-track tape when the 
SORTIN data set is on 9-track tape. 


2. May be on 7-track tape when the 
SORTOUT data set is on 9-track tape. 


3. Cannot use the data conversion feature 
if they are on 7-track tape. The 
TRICH subparameter must reflect this. 


4. May be on 9-track tape when the SORTIN 
data set is on 7-track tape. 


SORTWKnn Example A: The following DD 
statement parameters could be used to 
define a tape intermediate storage data 
set: 


/4/SORTWKO1 DD UNIT=2400, LABEL=(, NL) x 
4/ VOLUME=SER=DUMMY 


These parameters specify an unlabeled data 
set on a 2400-series tape unit. Since the 
DSNAME parameter is omitted, the system 
assigns a unique name to the data set. The 
omission of the DISP parameter causes the 
system to assume that the data set is new 
and that it should be deleted at the end of 
the current job step. The 2400-series tape 
units are explicitly of the 9-track format. 


SORTWKnn Example B: The following DD 
statement parameters could be used to 


define a direct-access intermediate storage 
data set: 


//SORTWKO1 DD UNIT=2311, X 
11 SPACE=(TRK, (200),, CONTIG), 


These parameters specify a disk (2311) data 
set with a standard label (LABEL parameter 
default value). The SPACE parameter speci- 
fies that the data set is to be allocated 
200 contiguous tracks. The system assigns 
a unique name to the data set and deletes 
it at the end of the job step. 


SYSTEM DD STATEMENTS 


In addition to the DD statements used by 
the SORT program itself, the following must 
be included in the execution time job step: 


“/SYSOUT DD SYSOUT=A 
//SORTLIB DD DSNAME=SYS1. SORTLIB, x 
/f DISP=OLD 


These DD statements are for the use of 
other components of the system that are 
concerned with the sorting operation. 


Note: At system generation time, SORT 
diagnostic messages can be assigned to 
print either on the console or on the unit 
designated SYSOUT. If the system is 
generated to write SORT messages on SYSOUT, 
these messages may overprint any COBOL out- 
put assigned to SYSOUT. For example, if 
the programmer has selected SYSOUT on which 
to print a report in the output procedure 
of a COBOL SORT program, any SORT messages 
will be interspersed within that report. 

If it is not possible to assign the SORT 
messages to the console, the programmer 
should assign his COBOL output to temporary 
files and print the reports at a later 
time. 


SHARING DEVICES BETWEEN TAPE DATA SETS 


A single tape unit may be assigned to 
two sort data sets when the data sets are 
one of the following pairs: 


e The input data set (SORTIN) and the 
first intermediate storage data set 
(SORTWKO1). 


e The input data set (SORTIN) and the 
output data set (SORTOUT). 


The AFF subparameter of the UNIT para- 
meter can be used to associate the SORTIN 
data set with either the SORTWK01 data set 
or the SORTOUT data set. It can appear in 
the DD statement for SORTWKO01 or SORTOUT. 


To use the Sort Feature with both the 
USING and GIVING options, where input and 
output are on the same tape unit, SORTOUT 
does not need to be defined in a SELECT... 
ASSIGN statement, provided that SORTIN is 
so defined. Only one FD entry is required, 
and that file-name will appear as the 
object of both the USING and GIVING 
clauses. (In this case, a SORTOUT DD 
statement must be present at execution time 
specifying UNIT=AFF with the SORTIN tape 
init.) 


JSING MORE THAN ONE SORT STATEMENT IN A JOB 


More than one SORT statement may be used 
in a Single program or in two or more pro- 
jrams that are combined into a single load 


module. If more than one USING clause is 
specified, all of the files named in the 
USING clauses must be associated with the 
SORTIN DD statement. However, only one 
SORTIN DD statement can be specified ina 
Single job step. Therefore, if more than 
one file is to be sorted during execution 
of a single job step, the INPUT PROCEDURE 
option can be used instead, and the file to 
be sorted need not be associated with 
SORTIN. 


Similarly, the OUTPUT PROCEDURE option 
can be used in place of the GIVING option. 


SORT PROGRAM EXAMPLE 


The following control cards could be 
used with the sample Sort feature program 
contained in the publication IBM System/360 


Operating System: COBOL Language, Form 
C28-6516: 

4/SORTEST JOB NY83870165, *J.SMITH* ,X 
4/ MSGLEVEL=1 

4/SORTIS3 EXEC COBFCLG 

//COB. SYSIN DD * 


(COBOL source program) 


//GO.SORTWKO1 DD UNIT=SYSDA, SPACE= X 
S/ (TRK, (200), ,CONTIG) 
//GO.SORTWKO2 DD UNIT=SYSDA, SPACE= X 
1/ (TRK, (200), , CONTIG) 
//GO.SORTWKO3 DD UNIT=SYSDA, SPACE= X 
11 (TRK, (200), , CONTIG) 
7/GO.SORTOUT DD UNIT=183, LABEL=(, NL), X 
11 VOLUME=SER=NONE, X 
1/ DCB=(RECFM=FB, X 
11 LRECL=72, X 
4/ BLKSIZE=72) 
//GO.SYSOUT DD SYSOUT=A 

//GO.SORTLIB DD DSNAME=SYS1.SORTLIB, X 
// DISP=OLD 

//GO.SYSIN DD UNIT=182, LABEL=(, NL), X 
11 VOLUME=SER=DUMMY 


In the GO.SYSIN and GO.SORTOUT DD state- 
ments the numbers in the UNIT parameters 
are names assigned to tape units in a spe- 
cific installation and are not standard 
names. The minimum number of SORTWKnn data 
sets are used; the sort operation can be 
optimized by using additional work data 
sets (see the publication IBM System/360 
Form C28- 
6543). 
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CATALOGING SORT DD STATEMENTS 


Since repeated use of the Sort Feature 
often involves the same execution time DD 
statements, the user may wish to catalog 
them (see "Cataloged Procedures"). 


SORT DIAGNOSTIC MESSAGES 


The messages generated by the Sort Fea- 
ture are listed in the publications IBM 
System/360 Operating System, Sort/Merge, 


Form C28-6543, and IBM System/360 Operating 


System: Messages, Completion Codes, and 
Storage Dumps, Form C28-6631. The identi- 


fying characters in a sort message are IER. 


LINKAGE WITH THE SORT/MERGE PROGRAM 


Communication between the Sort/Merge 
program and the COBOL program is maintained 
by the COBOL library subroutine IHDFSORT. 


If the INPUT PROCEDURE option of the 
SORT statement is specified, exit E15 of 
the Sort/Merge program is used. The return 
code indicating “insert records" is issued 
when a RELEASE statement is encountered, 
and the return code indicating "do not 
return" is issued when the end of the pro- 
cedure is encountered. 


If the OUTPUT PROCEDURE option is speci- 
fied, exit E35 of the Sort/Merge program is 
used. The return code indicating “delete 
records" is issued when a RETURN statement 
is encountered, and the return code indi- 
cating "do not return" is issued when the 
end of the procedure is encountered. 
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Completion Codes 


The Sort/Merge program returns a comple- 
tion code upon termination. This code may 
be interrogated by the COBOL program. The 
codes are: 


0 - Successful completion of Sort/ 
Merge 
16 - Unsuccessful completion of Sort/ 
Merge 


SUCCESSFUL COMPLETION: When a Sort/Merge 
application has been successfully executed, 
a completion code of zero is returned and 
the sort terminates. 

UNSUCCESSFUL COMPLETION: If the sort, dur- 
ing execution, encounters an error that 
will not allow it to complete successfully, 
it returns a completion code of 16 and ter- 
minates. (Possible errors include an out- 
of-sequence condition or an uncorrectable 
I-O error.) The publication IBM System/360 
Operating System: _ _Sort/Merge, Form C28- 
6543 contains a detailed description of the 
conditions under which this termination 
will occur. 


The returned completion code will be 
stored in a special register called TALLY 
by the COBOL library subroutine; an unsuc- 
cessful termination of the sort may then be 
tested for and appropriate action speci- 
fied. Note that the contents of TALLY will 
change with the execution of a SORT state- 
ment. The following is an example of the 
use of TALLY with the sort feature: 


SORT SALES-RECORDS ON ASCENDING KEY 
CUSTOMER-NUMBER, DESCENDING KEY DATE, 
USING FN-1, GIVING FN-2. 


IF TALLY NOT EQUAL TO ZERO, 
"SORT UNSUCCESSFUL" UPON CONSOLE, 
RUN. 


DISPLAY 
STOP 


Libraries are an integral part of the 
operating system. Some libraries have 
system-supplied names and system-supplied 
data. Other libraries have system-supplied 
names, but the data they contain may be 
specified by a user. Still other libraries 
have user-supplied names and user-supplied 
data. 


Libraries, in general, are made up of 
partitioned data sets. Any library with a 
user-supplied name and user-supplied data 
always is a single partitioned data set, 
which is a collection of independent sets 
of sequentially organized data, called mem- 
bers. All of the members within a parti- 
tioned data set have the same characteris- 
tics such as record format. When used to 
store programs, a partitioned data set con- 
taining load modules can contain only load 
modules; it cannot contain both load 
modules and object modules. 


Each partitioned data set is headed by a 
directory of entries pointing to the mem- 
bers that make up the library. Each member 
has a unique member name. A partitioned 
data set must reside on a single direct- 
access device, but some libraries can con- 
sist of a concatenation of more than one 
partitioned data set. 


Figure 37 shows the format of a library 
that is a single partitioned data set of 
four members. Space for the members of 
such a library and its directory is 
requested in the SPACE parameter of the DD 
statement when the library is created. 
Additional members can be added to a 
library at a later time. If additional 
space is required to store a member, allo- 
cation will be made in the amount specified 
by the secondary allocation in the SPACE 
parameter of the DD statement that was used 
when the library and its first member were 
created. Additional space cannot be allo- 
cated for the directory, however. Direc- 
tory space is allocated for the entire 
library when the library is created. If 
the original allocation was not large 
enough, the IEHMOVE utility program can be 
used to expand the directory size. If the 
directory is filled, no additional members 
can be added to the library. Following is 
an example of a DD statement that might be 
used to create a library: 


LIBRARIES 


//DD1 DD DSNAME=FILELIB(FILE1), x 
/ DISP=(NEW,CATLG), x 
J/ UNIT=2311, X 
71 SPACE=(TRK, (40,10,3)), X 
// VOLUME=SER=111111 


This statement specifies that a library 
named FILELIB is to be created and cata- 
loged in this job step. Its first member 
is named FILE1. Initial space allocated 
for data sets is to be 40 tracks, with 
additional allocation to be made, as neces- 
sary, in units of 10 tracks. In addition, 
space for three 256-byte records is to be 
allocated for the directory. The volume 
serial number is 111111. 


A member of a partitioned data set can 
be replaced or deleted. The system actual- 
ly accomplishes this by modifying or delet- 
ing the directory pointer to the member. 
The space occupied by the original member 
is not available for reuse. However, the 
MOVE or COPY control statement of the IEH- 
MOVE utility program can be used to make 
available the space previously occupied by 
the replaced or deleted member. (For 
further details, see IBM System/360 Operat— 


A programmer can use libraries already 
provided by the system, or he can create 
libraries of his own. In addition, certain 
library names recognized by the system may 
be assigned to partitioned data sets pro- 
vided by the system, by the programmer, or 
both. These libraries and their uses are 
discussed in the following paragraphs. 


LIBRARIES PROVIDED BY THE SYSTEM 


Link Library 


The link library is a partitioned data 
set that contains load modules to be 
executed. Unless specified otherwise, a 
load module name in an EXEC statement is to 
be fetched from the link library. Operat- 
ing system programs, such as the COBOL com- 
Piler, are usually contained in this 
library. 
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Format of a Library 


Figure 37. 


The link library can be used by the pro- 
grammer to store executable load modules at 
linkage editor time. The technique for 
doing this is described in “Linkage Editor 
Data Set Reyuirements." 


The link library is identified in a job 
control statement as SYS1.LINKLIB. 


Procedure Library 


The procedure library is a partitioned 
data set whose members are the cataloged 
procedures at an installation. They 
include the cataloged procedures provided 
by IBM. Procedures written at the instal- 
lation can be added to the procedure 
library with the IEBUPDTE utility program 
(see “Cataloged Procedures"). 


The system name for the procedure 
library is SYS1.PROCLIB. 


Sort Library 


The sort library is a partitioned data 
set that contains load modules from which 
the sort program is produced. 


It is identified by the name SYS1. 
SORTLIB (see “Using the Sort Feature"). 


COBOL Subroutine Library 


The COBOL subroutine library is a parti- 
tioned data set that contains the COBOL 
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library subroutines in load module form. 
These subroutines are included in a COBOL 
load module to perform such functions as 
data conversion and double precision arith- 
metic. The COBOL programmer does not refer 
directly to these subroutines; calling 
sequences to them are generated at compile 
time from certain Procedure Division state- 
ments, and they are incorporated into the 
load module at linkage editor time. A 
listing of subroutine names, functions, 
entry points, and size is given in Appendix 


The system name for the COBOL subroutine 
library is SYS1.COBLIB. 


AUTOMATIC CALL LIBRARY 


The automatic call library, defined by 
the SYSLIB DD statement in the linkage edi- 
tor job step, contains load modules or 
object modules that may be used as secon- 
dary input to the linkage editor. If the 
library contains object modules, it may 
also contain control statements. External 
symbols that are undefined after all pri- 
mary input has been processed cause the 
automatic library call mechanism to search 
the automatic call library for modules that 
will resolve the references. The COBOL 
subroutine library must be specified for 
the automatic call library if any of the 
subroutines will be needed to resolve 
external references. Other partitioned 
data sets may be concatenated as shown in 
the following example: 


e Figure 38. 


//SYSLIB DD DSNAME=SYS1.COBLIB, DISP=OLD 
4/ DD DSNAME=MYLIB, DISP=OLD 


In this case, both the COBOL subroutine 
library and the partitioned data set named 
MYLIB are available to the automatic 
library call. 


Note: If the partitioned data set named in 
the SYSLIB DD statement contains load 
modules, any data set concatenated with it 
must also be a load module partitioned data 
set. If the first contains object modules, 
the others must also contain object 
modules. 


The linkage editor LIBRARY control 
statement has the effect of concatenating 
any specified member names with the auto- 
matic call library. 


COBOL COPY LIBRARY 


The COBOL copy library is a user-created 
library consisting of statements or entire 
COBOL programs frequently used by the pro- 
grammer. The programmer can include these 
statements or programs into a program at 
compile time. He calls them with the COBOL 
clauses COPY, INCLUDE, or BASIS. 


To enter or update source statements in 
the copy library, a utility program must be 
used. IEBUPDTE is the IBM-supplied utility 
program used to do this. A full discussion 
of the statements used in this program may 


a A ee SE ee ce a ane ee ce ce cm ce ce ce cee a a ee ce ee ee ee ee ee ee ee ce ee ee eee ee ee 


| 

| BLOCK CONTAINS 13 RECORDS 

| RECORD CONTAINS 120 CHARACTERS 
| LABEL RECORDS ARE STANDARD 

| DATA RECORD IS FILE-OUT. 

| 

I 


| // CATALOG JOB | 
|// EXEC PGM=IEBUPDTE, PARM= (NEW) | 
| //SYSUT2 DD DSNAME=COPYLIB, UNIT=2311, x| 
|/7 DISP=(NEW, KEEP), X| 
\// VOLUME=SER=111111, X| 
\// SPACE=(TRK, (15,10, 2)), x | 
|// DCB= (, RECFM=F, BLKSIZE=80) 
| //SYSPRINT DD SYSOUT=A | 
| //SYSIN DD * | l 
|./ ADD NAME=CFILEA, LEVEL=00, SOURCE=0, LIST=ALL | 
o/ NUMBER NEW1=10, INCR=5 | 
| 

| 

| 

| 

| 

| 


/ ENDUP 
* 


be found in the publication, IBM System/360 


Operating System: Utilities, Form 
C28-6586. 


Entering Source Statements 


Figure 38 illustrates the method to 
insert source statements into a copy 
library member. 


The utility statement ./ ADD copies 
CFILEA into the library called COPYLIB. 
CFILEA describes an FD entry. The NUMBER 
statement assigns a sequential numbering 
system to the statements in the library. 
The first statement is assigned number 10. 
and each succeeding statement is incre- 
mented by 5. The entries following the 
utility statements are the actual source 
statements to be inserted into the number. 
The ENDUP statement signals the end of the 
entries to be inserted. 


This same procedure can be used to 
include entire source programs into a 
library. 


Figure 39 illustrates the method to 
update source statements in the copy 
library member inserted in the previous 
example. 


ee ae ee ee a a 1 


Entering Source Statements Into the Copy Library 
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// UPDATE JOB 


|// EXEC PGM=IEBUPDTE, PARM= (MOD) l 
| //SYSUT1 DD DSNAME=COPYLIB, UNIT=2311, X 
|4/ DISP=(OLD, KEEP), X| 
\// VOLUME=SER=111111, X| 
|\7/ SPACE=(TRK, (15,10,2)), X| 
\/7 DCB=(, RECFM=F, BLKSIZE=80) | 
| //SYSUT2 DD DSNAME=COPYLIB, UNIT=2311, X| 
\// DISP=(OLD, KEEP), X| 
|// VOLUME=SER=111111, X| 
\// SPACE=(TRK, (15,10, 2)), X| 
\// DCB=(, RECFM=F, BLKSIZE=80) | 
| //SYSPRINT DD SYSOUT=A | 
| //SYSIN DD * | 
1./ CHANGE NAME=CFILEA, LEVEL=01, SOURCE=0, LIST=ALL | 
| BLOCK CONTAINS 20 RECORDS 00000010 
| ./ ENDUP 

174 | 


Figure 39. 


SYSUT1 and SYSUT2 describe the old and 
the new data sets. Note that changes may 
be made on the same data set (identified by 
the DSNAME parameter). The utility state- 
ment CHANGE indicates that the new entry of 
CFILEA replaces the old entry. The 
sequence number of the altered statement 
must be supplied. This number, 00000010, 
is in dicated in columns 73-80 of the 
replacement source statement. Note that, 
although in the insert example (Figure 38, 
the NUMBER statement) the number was coded 
as 10 without leading zeros, the program 
assigns an 8-character field to a sequence 
number and pads with leading zeros if 
necessary. When updating a sequence number 
in a library, these leading zeros must be 
included. 


At compile time, COPYLIB is identified 
on a SYSLIB DD statement, as follows: 


//SYSLIB DD  DSNAME=COPYLIB, x 
If VOLUME=SER=111111, X 
1/7 DISP=OLD, UNIT=2311 


Members of the cataloged library can be 
retrieved using the COPY, INCLUDE, or BASIS 
clauses. 


The COPY Clause 


The COPY clause permits the programmer 
to include members of a library containing 
source statements into the Data or Environ- 
ment Divisions. If the programmer wishes 
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Updating Source Statements in a Copy Library 


to retrieve the member, CFILEA, inserted in 
the previous examples, he writes the 
statement: 


FD FILEA COPY ‘CFILEA' 


The compiler translates this instruction to 
read: 


FD FILEA BLOCK CONTAINS 20 RECORDS 
RECORD CONTAINS 120 CHARACTERS 
LABEL RECORDS ARE STANDARD 
DATA RECORD IS FILE-OUT. 


Note that CFILEA itself does not appear in 
the statement. CFILEA is a name identify- 
ing the entries. It acts as a header 
record but is not itself retrieved. The 
compiler source listing, however, will 
print out the COPY statement as the pro- 
grammer wrote it. 


The INCLUDE Clause 


“The INCLUDE clause permits the pro- 
grammer to include members of a library 
containing source statements into the Pro- 
cedure Division. It is implemented like 
the COPY clause. 


Assume a procedure named DOWORK was 
inserted with the following statements: 
-/ ADD NAME=DOWORK, LEVEL=00, 

SOURCE=0, LIST=ALL 
of NUMBER SEQ1=400, INCR=10 
COMPUTE QTY-ON-HAND = TOTAL-USED- 
NUMBER-ON-HAND. 
MOVE-QTY-ON-HAND TO PRINT-AREA. 
of ENDUP 


To retrieve the member, DOWORK, the pro- 

grammer writes: 
Paragraph-name. INCLUDE '‘DOWORK'. 

The statements included in the DOWORK pro- 

cedure will immediately follow the 

paragraph-name, replacing the words INCLUDE 

*"DOWORK*. 


The BASIS Clause 


Frequently used source programs, such as 
a payroll program, can be inserted into the 
copy library. The BASIS clause brings in 
an entire source program at compile time. 
Calling in a cataloged program eliminates 
the need for the programmer to handle a 
program each time he wants to compile one. 
The programmer may, however, alter any 
statement in the source program by refer- 
ring to its COBOL sequence number with an 
INSERT or DELETE statement. The INSERT 
statement adds new source statements after 
the sequence number indicated. The DELETE 
statement deletes the statements indicated 
by the sequence numbers. The programmer 
may delete a single statement with one 
sequence number, or may delete more than 
one statement with the first and last 
sequence numbers to be deleted separated by 
a hyphen. 


Note: The COBOL sequence number is the 
6-digit number which the programmer assigns 
in columns 1-6 of the source cards. This 
sequence number has no connection with the 
sequence numbers assigned in simulated 
columns 73-80 by the IEBUPDTE utility pro- 
gram. The sequence numbers assigned by 
IEBUPDTE are used to update source state- 
ments in the copy library, and are intended 
to be permanent changes. The COBOL 


sequence numbers are used to update COBOL 
source statements at compile time and are 
in effect for the one run only. 


Assume that a company payroll program is 
kept as a source program member in from a 
copy library. The name of the program is 
PAYROLL. During the year, social security 
tax (FICA) is taken out at a rate of 4.40 
percent each week for all personnel until 
earnings exceed $6600. The coding to 
accomplish this is shown in Figure 40. 


Now, however, due to a change in the 
Social Security laws, FICA is to be taken 
out ‘until earnings exceed $7800. Assume 
also that at this time the company is spon- 
soring a drive for contributions to the 
local children's aid fund. All employees 
have been asked to contribute on a volun- 
tary basis. Each employee record in the 
input data set contains two fields, OTHER- 
CODE and OTHER-DOLLAR, to handle various 
contributions. If OTHER-CODE is coded Y, 
the employee has agreed to contribute the 
dollar amount shown in OTHER-DOLLAR. The 
programmer can make these changes as 
follows: 


//GOe«SYSIN DD * 
BASIS *PAYROLL* 
DELETE 000730 
IF ANNUAL-PAY GREATER THAN 7800 GO TO 
PAY-WRITE. 
INSERT 000770 
IF CONTRIB="Y* GO TO FUND-PAY. 
INSERT 000850 


FUND-PAY. SUBTRACT OTHER-DOLLAR FROM 
BASE-PAY. 
MOVE OTHER-DOLLAR TO 
OUTPUT-OTHER. 
EX1. EXIT. 


The altered program will contain the cod- 
ing shown in Figure 41. 


Sa a Se ea eee : 
| 


[porno +--+ +--+ ++ 
|] COBOL IEBUPDTE 
| Sequence Sequence | 
{Numbers Numbers _| 
| 000730 IF ANNUAL-PAY GREATER THAN 6600 GO TO | 
| PAY-WRITE. 00000110 | 
}000740 FICA-PAYR. COMPUTE FICA-PAY = BASE-PAY * .044 00000115| 
[900750 MOVE FICA-PAY TO OUTPUT-FICA. 00000120 | 
}000760 PAY-WRITE. MOVE BASE-PAY TO OUTPUT-BASE. 00000125] 
|000770 ADD BASE-PAY TO ANNUAL-PAY. 00000130 | 
| oe e a « if 
& : - 
{900850 STOP RUN. 00000240 | 
bee emo aaa ee Sas ea ea ee al ae ee a lei ee ee ee ee ee ee J 
Figure 40. COBOL Statements to Deduct FICA Tax. 
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SR eS cn A a Raa aa a aa ihc am a a a aw a a ALR EAE 1 
| COBOL IEBUPDTE | 
| Sequence Sequence | 
| Numbers Numbers | 
{z IF ANNUAL-~PAY GREATER THAN 7800 GO TO | 
r PAY-WRITE. | 
{000740 FICA~PAYR. COMPUTE FICA-PAY = BASE-PAY * .044 00000115 | 
{000750 MOVE FICA-PAY TO OUTPUT-FICA. 00000120 | 
| 900760 PAY-WRITE. MOVE BASE-PAY TO OUTPUT-BASE. 00000125] 
} 000770 ADD BASE-PAY TO ANNUAL-PAY. 00000130 | 
|Z IF CONTRIB="'¥' GO TO FUND-PAY. | 
1 . ° ° | 
| e ° . | 
|} 900850 STOP RUN. 00000240 | 
{I FUND- PAY. SUBTRACT OTHER-DOLLAR FROM BASE-PAY. | 
{I MOVE OTHER-DOLLAR TO OUTPUT-OTHER. | 
jI EX1. EXIT. | 
a a ee ge et ee ee ee ee a ee J 
Figure 41. Changed COBOL Statements to Update FICA Example. 


Note that changes made through use of 
the INSERT and DELETE statements remain in 
effect for the one run only. 


New statements brought into the program 
by INSERT cards are identified by the 
letter I in the COBOL sequence number 
field. 


Note: If BASIS and COPY are both used, the 
library containing the member specified in 
the BASIS card must be defined first. The 
COPY libraries concatenated with the BASIS 
library may be defined and referenced in 

any order. See the section "A Check List 

for Job Control Procedures" for an example. 





JOB LIBRARY 


The job library consists of one or more 
partitioned data sets which contain load 
modules to be executed. It is specified by 
the JOBLIB DD statement which must precede 
the EXEC statement of the first step of a 
job. Partitioned data sets assigned to the 
job library are concatenated with the link 
library so that any load module is obtained 
automatically when its name appears in the 
PGM= parameter of the EXEC statement. The 
following statements illustrate how three 
partitioned data sets can be assigned to 
the job library: 


//MYJOB JOB eee 
4/JOBLIB DD DSNAME=MYLIB1, DISP=(OLD, PASS) 
4/ DD DSNAME=MYLIB2, DISP=(OLD, PASS) 
47 DD DSNAME=MYLIB3, DISP=(OLD, PASS) 
//STEPL EXEC eee 
S/STEP2 EXEC wee 
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These statements specify that the ‘job 
library containing the data sets MYLIB1, 
MYLIB2, and MYLIB3 is to be concatenated 
with the link library. When a load module 
is named in an EXEC statement in any step 
of the job, the directories of the job 
library will be searched for the name. 
When a job library is specified for a job, 
the link library is searched for a named 
load module only if the module is not found 
in the job library. 


Partitioned data sets used in the job 
library can be created by specifying the 
partitioned data set name and the member 
name in the SYSLMOD DD statement when each 
member is processed by the linkage editor. 


LIBRARIES CREATED BY THE USER 


As discussed previously, a programmer 
can create members of the link library, the 
procedure library, and the job library. He 
can also create partitioned data sets for 
use in the copy library, the automatic call 
library, and the job library. In addition, 
he can create partitioned data sets to be 
used as libraries for additional input to 
the linkage editor, and he can create 
libraries whose members are source program 
entries. 


Libraries of object modules (with or 
without linkage editor control statements) 
and libraries of load modules can be used 
as additional input to the linkage editor. 
Members are specified by use of the INCLUDE 
and LIBRARY linkage editor control 
statements. 


A library of object modules and control 
statements can be created by use of the 
IEBUPDTE utility program. 


A library of load modules can be created 
by use of the SYSLMOD DD statement in the 
linkage editor job step, as discussed in 
“Job Library." 


CREATING AND CHANGING LIBRARIES 


A programmer can create or change a par- 
titioned data set in one of three ways: 
(1) through the use of DD statements, (2) 
through the use of utility programs, and 
(3) through the use of certain linkage edi- 
tor control statements. | 


The DD statement can be used to create 
libraries as is discussed at the beginning 
of this chapter. In addition, DD state- 
ments can be used to add members to exist- 


ing libraries, including the link library, 
to retrieve members of existing libraries. 


Utility programs can be used to create 
libraries such as those used in the copy 
library or as secondary input to the link- 
age editor. In addition, utility programs 
can be used to move, copy, and replace mem- 
bers of an existing library; to add, 
delete, and renumber the records within an 
existing library; and to assign sequence 
numbers to the records of a new library. 


Linkage editor control statements can be 
used to make changes to members of a 
library of load modules. The name of a 
member can be changed or additional names 
can be specified. Additional entry points 
can be identified, existing entry points 
can be deleted, and portions of a load 
module can be deleted or replaced. For 
further information, see IBM System/360 
Operating System: Linkage Editor, Form 
C28-6538. 
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A COBOL program can refer to and pass 
control to other COBOL programs, or to pro- 
grams written in other languages. A pro- 
gram in another language can refer to and 
pass control to a COBOL program. A program 
program. A program that is referred to is 
a called program. Control is returned from 
a called program to the first instruction 
foklowing the calling sequence in the cal- 
ling program. 


A called program can also be a calling 
program; that is, a called program can, in 
turn, call another program. However, a 
called program can not call the program 
that called it or an earlier calling pro- 
gram. Control is returned in the same 
order of calling; that is, a called program 
usually returns control to its own calling 
program, not to an earlier calling program. 
Computer generated switches, e.g., ON and 
ALTER, are reinitialized upon each entrance 
to the called program. 


All called and calling programs to be 
executed as a single job step must be link- 
age edited together; they must all be 
included in the same load module. 


This chapter describes the accepted 
linkage conventions for calling and called 
programs in both COBOL and assembler lan- 
guage and discusses how such programs are 
linkage edited. In addition, it includes a 
discussion of overlay design in which dif- 
ferent called programs may, at different 
times, occupy the same area in main 
storage. 


SPECIFYING LINKAGE 


Whenever a program calls another pro- 
gram, a link must be established between. 
the two. The calling program must state 
the entry point of the called program and 
must specify any arguments to be passed. 
The called program must have an entry point 
and must be able to accept the arguments. 
In addition, the called program must estab- 
lish the linkage for the return of control 
to the calling program. 


LINKAGE IN A CALLING COBOL PROGRAM 


A calling COBOL program must contain the 
following statements at the point where 
another program is to be called: 


CALLING AND CALLED PROGRAMS 


ENTER LINKAGE. 
CALL entry-name 
ENTER COBOL. 


{USING argument-list]. 


The entry-name is the name of the entry 
point in the called program to which con- 
trol is to be transferred. The argument 
list is one or more data-names, separated 
by blanks, that are to be passed to the 
called program. 


If the called program is an assembler 
language program, the argument list may 
also include file-names and procedure- 
names. If the argument contains a file- 
name, the COBOL (F) compiler passes the 
address of the DCB (data control block) for 
a queued file, or the address of the DECB 
(data event control block) for a basic 
file, as an entry of the argument list. 
This can be used to test bits in the DCB or 
DECB or to enter some options in the DCB by 
a called assembler language subroutine. 
However, when changing a field of the DCB, 
precautions should be taken not to contra- 
dict the information in other fields or the 
information in the object codes supplied by 
the compiler, job control language, or 
other sources. If no arguments are passed, 
the USING clause is omitted. 


LINKAGE IN A CALLED COBOL PROGRAM 


A called COBOL program must contain two 
sets of statements. 


The following statements must be 
inserted to name the point where the pro- 
gram is to be entered: 


ENTER LINKAGE, 
ENTRY entry-name [USING parameter-list]. 
ENTER COBOL. 


The entry-name is the name of the entry 
point in the called program. It is the 
same name that appears in the CALL state- 
ment of the program that calls this pro- 
gram. The parameter list is one or more 
data-names that correspond to the arguments 
of the CALL statement of the calling pro- 
gram. Each data-name of the parameter list 
must be defined in the Linkage Section of 
the Data Division and must have a level 
number of 01 or 77. 


The following statements must be 


inserted at the point where control is to 
be returned to the calling program: 
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ENTER LINKAGE. 
RETURN. 
ENTER COBOL. 


The RETURN statement enables restoration of 
necessary registers and it returns control 
to the point in the calling program immedi- 
ately following the calling sequence. 


Correspondence of Arguments and Parameters 


The number of data-names in the argument 
list of a calling program must be the same 
as the number of data-names in the param- 
eter list of the called program. There is 
a one-for-one correspondence; that is, the 
first argument is passed to the first 
parameter, the second argument to the 
second parameter and so forth. 


Only the address of an argument is 
passed. Consequently, the data-name that 
is an argument and the data-name that is 
the corresponding parameter both refer to 
the same locations in main storage. The 
pair of names, however, need not be 
identical, but the data descriptions must 
be equivalent. For example, if an argument 
is a 77 level data-name of a character str- 
ing of length 30, its corresponding para- 
meter also could be a 77 level data-name of 
a character string of length 30, or the 
parameter could be a 01 level name with 
subordinate names representing character 
strings whose combined length is 30. 


Although all parameters in the ENTRY 
statement must be described with level num- 
bers of 01 or 77, there is no such restric- 
tion made for arguments in the CALL state- 
ment. An argument may be a qualified name 
Or a subscripted name. When a group item 
with a level number other than 01 is speci- 
fied as an argument, proper word-boundary 
alignment is required if subordinate items 
are described as COMPUTATIONAL, COMPUTA- 
TIONAL-1, or COMPUTATIONAL-2. If the argu- 
ment corresponds to a 01-level parameter, 
doubleword alignment is required. 


LINKAGE IN A CALLING OR CALLED 
ASSEMBLER-LANGUAGE PROGRAM 


In a COBOL program, the expansions of 
the ENTER LINKAGE statement provide the 
save and return coding that is necessary to 
establish linkage between the calling and 
the called programs. Assembler language 
programs must be prepared in accordance 
with the basic linkage conventions of the 
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operating system. Table 15 shows the con- 
ventions for use of general registers as 
linkage registers. 


Conventions Used_in_a Calling Assembler 
Language_Program 


A calling assembler language program 
must reserve a save area of 18 words, 
beginning on a fullword boundary, to be 
used by the called program for saving 
registers. It must load the address of 
this area into register 13. If the program 
is to pass arguments, an argument list must 
be prepared, and the address of the argu- 
ment list must be loaded into register 1. 
The calling program must load the address 
of the return point into register 14, and 
it must load the address of the entry point 
of the called program into register 15. 


Table 15. Linkage Registers 

fo feo ee Tose Se 1 
]Register|Register | | 
|Number | Use }Contents | 
f 1 JArgument |Address of the argu-| 
] jRegister | ment list that is | 
| | | passed to the called} 
| | program. | 
] 13 |Save Area|Address of an area (of | 
] {Register ] 18 full words) to be| 
1 | } used by the called | 
t | ] program to save | 
| | | registers. | 
| | | | 
| 14 | Return |Address of the loca-| 
| |Register | tion in the call-| 
] | {| ing program to which| 
] | } control should be 

| | } returned after 

| } execution of the 

] | ] called program. 

{ | | 

} 15 | Entry {Address of the entry 
] | Point | point in the called 
] |Register1+] program to which 

] | | control is to be 

] | | transferred. 
}-------- Bee ee ee Ae ee eee 


tRegister 15 also is used as a return 
code register. The return code in- 
dicates whether or not any exceptional 
conditions occurred during execution of 
the called program. A COBOL program 
connot generate a return code, nor can 
a COBOL program test a return code 
returned to it from an assembler lan- 
guage program. A return code can be 
used, however, if both the calling and 
called programs have been written using 
the assembler language. 
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(Calling Sequence) 


Note: 


| | 
{ | 
| | 
| | 
| LA 1, ARGLST Loads into register 1 the address of the argument list to | 
| be passed. | 
{ | 
| LA 13, AREA Loads into register 13 the address of the save area to be | 
| passed. : | 
| | 
H CALL CALLED Transfers control to the entry point of the called | 
| . program. (The CALL macro-instruction generates coding | 
| ‘ that loads a V-type address constant of CALLED into | 
| e register 15 and that places into register 14 the return | 
| address, that is, the address of the first byte | 
{ following the macro-expansion. ) | 
| | 
| (Save Area) | 
| | 
| AREA Dc 18F Reserves the save area of 18 full words to be passed to | 
| the called program. | 
| | 
| (Argument List) | 
{ | 
JARGLIST DC A(ARG1,ARG2) Creates address constants for the first two arguments of | 
| the argument list (called ARG1 and ARG2). | 
| | 
| Dc x'8o0° Sets the first bit of the next word to one. | 
| | 
| Dc AL3 (ARG3) Creates an address constant for this argument and stores | 
| it in the last three bytes of the word. Since the | 
{| first bit of the first byte of the word is a one, this | 
| third argument is specified to be the last argument of | 
| the list. | 
|-~------------------------------------------------------------------------------------- { 


Since the calling program containing this coding would have previously been 


calied by the COBOL program, it also could establish linkage between the save area it 


I | 
| | 
| has received and the save area it passes to the called program. | 
] word three of the old save area the address of the new save area, and it would store | 
l | 

J 


It would store in 


in word two of the new save area the address of the old save area. 


Figure 42. 


The argument list is a group of contig- 
uous fullwords, each of which is an address 
of a data item to be passed to the called 
program. The argument list must begin on a 
fullword boundary. The high-order bit of 
the last argument, by convention, is set as 
a flag of 1 to indicate the end of the 
list. Figure 42 shows a portion of an 
assembler language program that illustrates 
the conventions used in a calling program. 


Conventions Used in a Called Assembler 
Lanquage Program 


A called assembler language program must 
save the registers and store other 
pertinent information in the save area 


Sample Linkage Coding Used in a Calling Assembler-Language Program 


passed to it by the calling program (the 
layout of the save area is shown in Figure 
43). A called program must also contain a 
return routine that (1) loads the address 
of the save area back into register 13, (2) 
restores the contents of other registers, 
(3) loads the return address in register 
14, and (4) optionally sets flags in the 
high-order eight bits of word 4 of the save 
area to all ones to indicate that the 
return occurred. It can then branch to the 
address in register 14 to complete the 
return. 


Figure 44 shows a portion of an assem- 
bler language program that illustrates the 
conventions used in called programs. 
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Not used by COBOL or 


Address (stored by the 


Return address (con- 


Entry point address 


Contents of register 0 


Contents of register 1 


Contents 


assembler-language 
programs. 


calling program) of 
the save area used by 
the calling program. 
This is the address 
of a save area that 
was passed to the 
calling program by 
the program that 
called the calling 
program. 


called program) of 
the next save area, 
that is, the save 
area that the called 
program provides for 
a program that it 
calls. The called 
program need not 
reserve a save area 
if it does not, in 
turn, call another 
program. 


tents of register 14) 
stored by the called 
program. 


(contents of register 
15) stored by the 
called program. 


(stored by the called 
program). 


(stored by the called 
program); that is, 
the address of the 
argument list passed 
to the called 
program. 


of registers} 
2 through 12 (stored — 
by the called pro-' 
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Save Area Layout and Contents 


FILE-NAME AND PROCEDURE-NAME ARGUMENTS 


A calling COBOL program that calls an 
assembler language program can pass file- 
names and procedure names, in addition to 
data-names, aS arguments. In the actual 
argument list that the compiler generates, 
the procedure-name is passed as the address 
of the procedure. For a queued file, the 
file-name is passed as the address of the 
DCB; for a basic file, the file-name is 
passed as the address of the DECB. 


LINKAGE EDITING PROGRAMS 


Each time an entry point is specified in 
defined. An external name is a name that 
can be referred to by another separately 
compiled or assembled program. Each time 
an entry name is specified in a calling 
program, an external reference is defined. 
An external reference is a symbol that is 
defined as an external name in another 
separately compiled or assembled program. 
The linkage editor resolves external names 
and references and combines calling and 
called programs into a format suitable for 
execution together, i.@e, aS a single load 
module. 


Load modules of both calling and called 
programs are used as input to the linkage 
editor. There are two kinds of input, pri- 
mary and additional. Primary input con- 
sists of a sequential data set that con- 
tains one or more separately compiled 
object modules and/or linkage editor con- 
trol statements. The primary input can 
contain object modules that are either 
calling or called programs or both. Addi- 
tional input consists of object modules or 
load modules that are not part of the pri- 
mary input data set but are to be included 
in the load module. The additional input 
may be in the form of (1) a sequential data 
set consisting of one or more object 
modules with or without linkage editor con- 
trol statements, or (2) libraries contain- 
ing object modules with or without linkage 
editor control statements, or (3) libraries 
consisting of load modules. The additional 
input is specified by linkage editor con- 
trol statements in the primary input and a 
DD statement for each additional input data 
set. Additional input may contain either 
calling or called programs or both. 


Note: Each additional input data set may 
itself contain external references or names 
and linkage editor control statements that 
specify more additional input. 


SPECIFYING PRIMARY INPUT 


The primary input data set is specified 
for linkage editor processing by the SYSLIN 
DD statement. The linkage editor must 
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ENTRY CALLED 


(Save Routine) 


CALLED SAVE (14,10) 


4, Se 6, 


LR 2,13 


LM 3,5,0(1) 


(Return Routine) 


LR 13,2 


RETURN (14,10)),/T 


(14, 
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| Note: 


Stores the contents of registers 14, 15, 0, 
and 7 of the save area. 
linkage registers. 
not actually used in linkage, 
words Of the save area. 
registers 11 and 12 is that they will not be used in 
this program. 
them since their contents will be unchanged when control 
is returned. 
instruction uses register 13, which contains the address 
of the save area, 


Loads into registers 3, 4, 
three arguments passed to the program. 
the argument list always is passed in register 1, which 
here is used as the base register to get the addresses. 
Subsequent references to the first argument will use 
register 3 as the base register for that address. 
References to the second and third arguments will use 
registers 4 and 5. 
could be used in calling this program, each argument 
would be tested for a one in the high order bit.) 


restored to register 14, 
branch to that instruction. 
instruction causes the eight high-order bits of word 4 

of the save area to be set to ones as an indication that 
the return occurred. 


If the called program containing this coding also calls another program, it | 


always have a primary input data set speci- 
fied by a SYSLIN DD statement whether or 
not there are called or calling programs 
and even if the primary input data set con- 
tains only linkage editor control state- 
ments. The SYSLIN DD statement that speci- 
fies the primary input is discussed in the 
chapter “Linkage Editor Data Set Require- 
ments." See “Example of Linkage Editor 
Processing" for a discussion of how to 
specify a primary input data set that con- 
tains more than one object module along 
with linkage editor control statements. 
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Establishes CALLED as an external name that can be 
referred to in another program. 


and 1 in words 
These are conventional 
Registers 2 through 10, which are 
are saved in subsequent 
The implication in not saving 


Consequently there is no need to save 
The expanded code of the SAVE macro 


in effecting the storage of registers. 


Loads the address of the save area into register 2, which 
subsequently will be used to refer to the save area. 


The address of 


(If a variable length argument list 


Loads into register 13 the address of the save area that 
was passed to this program. 


This RETURN macro instruction restores the saved registers 
15, and 0 through 10). 


The return address is 
and the expansion includes a 
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jwould contain the calling sequence, and it would establish linkage between the save | 
Jarea it had received and the save area it passes to the called program. | 


Figure 44, 


Sample Linkage Coding Used in a Called Assembler Language Program 
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| 7/JOBX JOB 

|“/STEP1 EXEC PGM=IEQCBL00, PARM=LOAD 

| e 

! P 

{|“/7/SYSLIN DD DSNAME=&GOFILE, DISP= (MOD, PASS) , UNIT=SYSSQ 
| //SYSIN DD * 

{ (Source module for MAIN, a calling program) 

|7* 

| //STEP 2 EXEC PGM=IEQCBL00, PARM=LOAD 

! ° 

° 

|7/SYSLIN DD DSNAME=*,. STEP1. SYSLIN, DISP=(MOD, PASS) 
| //SYSIN DD * 

| (Source module for ADD, a called program) 

\7* 

| “7/STEP3 EXEC PGM=IEQCBLOO, PARM=LOAD 

1 : 

° 

|7/7SYSLIN DD DSNAME=*,. STEP2. SYSLIN, DISP=(MOD, PASS) 
| //SYSIN DD * 

| (Source module for SUBTRACT, a called program) 
|7* 

|4/STEP4 EXEC PGM=ITEWL 

| : 

| ° 

|77SYSLIB DD DSNAME=SYS1. COBLIB, DISP=OLD 

| 7/SYSLMOD DD DSNAME=PROGLIB(CALC) , DISP=OLD 
|7/ADDLIB DD DSNAME=MYLIB, DISP=OLD 

|7/SYSLIN DD DSNAME=&GOFILE, DISP=OLD 

|// DD * 

| INCLUDE ADDLIB(A) 

| LIBRARY  ADDLIB (X,Y, 2) 

i7* 

a ee eee 

Figure 45. Specifying Primary and Additional Input to the Linkage Editor 


SPECIFYING ADDITIONAL INPUT 


Additional input data sets are specified 
by linkage editor control statements and a 
DD statement for each additional input data 
set. 


The linkage editor control statements 
that specify additional input are INCLUDE 
and LIBRARY.1 A primary input data set may 
consist entirely of such statements. 
INCLUDE and LIBRARY statements may be 
placed before, between, or after object 
modules or other control statements in 
either primary or additional input data 
sets. One method of using these statements 
is shown in Figure 45. 


1The operation field in a linkage editor 
control statement must start after column 
1. The operand field must be preceded by 
at least one blank. 


150 


Note: Additional input often contains men- 
bers of libraries. See "Specifying 
Libraries As Additional Input" in the 
chapter "Libraries" for more information. 


INCLUDE Statement 


The INCLUDE statement is used to include 
an additional input data set that is either 
a member of a library or a sequential data 
set. Its format is: 


7 
+ 

INCLUDE } ddname[ (member~-name | 
1 {,member-name]...)] | 
] {, ddname { (member-name | 
] {,member-name...])]]... | 
4 


where ddname indicates the name of the DD 
Statefnent that specifies the library or 
sequential data set, and member-name is the 
name of the library member that is to be 
included. Member-name is not used when the 
additional input data set is not a member 
of a partitioned data set. 

Note: The linkage editor INCLUDE statement 
should not be confused with the COBOL lan- 
guage INCLUDE statement. 


LIBRARY Statement 


The LIBRARY statement is used to include 
additional input that may be required to 
resolve external references. 


The format is: 


Dee eee ee ne as ee ee eae ee 1 
| Operation | Operand | 
}----------- }----------------------------- { 
| LIBRARY ] ddname (member-name | 
| | {,member-name]...) | 
| ] {, ddname (member-name | 
| i {,member-name..e]) Jee. H 
igloos oe es ENP fot Nc oe ea eee oe rey a Od So J 


where ddname indicates the name of the DD 
statement that specifies the library, and 
member-name is the name of the member of 
the library. 


The LIBRARY statement differs from the 
INCLUDE statement in that libraries speci- 
fied in the LIBRARY statement are not 
searched for additional input until all 
other processing, except references re- 
served for the automatic library call, is 
completed by the linkage editor. Any addi- 
tional module specified by an INCLUDE 
statement is included immediately, whenever 
the INCLUDE statement is encountered. 


LINKAGE EDITOR PROCESSING 


The linkage editor first processes the 
primary input and any additional input 
specified by INCLUDE statements. All 
external references that refer only to 
other modules in the primary and included 
input are resolved. If there are still 
unresolved references after this input is 
processed, the automatic call library, 
which includes. libraries specified by the 
SYSLIB DD statement and by the LIBRARY sta- 
tements, is searched to resolve the refer- 
ences. The automatic call library general- 
ly will contain the COBOL library subrou- 
tines. (External references to these sub- 
routines are generated by the COBOL compil- 


er when statements in the source module 
require certain functions to be performed, 
such as some data conversions. ) 


If the additional input contains 
external references and/or linkage editor 
control statements, the references are 
resolved in the same way. Data sets speci- 
fied by the INCLUDE statement are included 
when the statement is encountered. Data 
sets specified by the LIBRARY statement are 
used only if there are unresolved refer- 
ences after all of the other processing is 
completed. 


Figure 45 shows the control statements 
for a job that separately compiles three 
source modules (one is a calling program 
and two are called programs) and places 
them in one data set as primary input for 
the linkage editor. The linkage editor 
then links them together with additional 
input (called programs that are members of 
the specified library) to form one load 
module. 


STEP1 compiles a source module called 


MAIN, STEP2 compiles a source module called 
ADD. STEP3 compiles a source module called 
SUBTRACT. The object module from each step 


is placed in the sequential data set called 
&GOFILE. (Since MOD and PASS are specified 
for &GOFILE in the SYSLIN DD statement in 
STEP1, the object modules ADD and SUBTRACT 
are placed in the data set behind the 
object module, MAIN.) 


In STEP4 the linkage editor uses the 
&6GOFILE data set as primary input, and the 
cataloged libraries MYLIB and SYS1.COBLIB 
as additional input. (The INCLUDE and 
LIBRARY statements become part of the pri- 
mary input through the DD * statement fol- 
lowing the SYSLIN DD statement.) 


The object modules of the data set 6&GO- 
FILE and the member A of MYLIB are proc- 
essed first. If there are unresolved 
references after this input is processed, 
the linkage editor searches the automatic 
call library, which includes the COBOL sub- 
routine library and members X, Y and Z of 
MYLIB, to resolve these references. MYLIB 
is specified in the ADDLIB DD statement. 


After linkage editor processing is com- 
pleted, the load module CALC is added as a 
member to the existing, cataloged library 
PROGLIB. CALC now contains MAIN, SUBTRACT, 
ADD, A, and, possibly, COBOL subroutines, 
and X, Y, and Z. 
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OVERLAY STRUCTURES 


If the called programs needed to execute 
one COBOL source program do not all fit 
into main storage at the same time, it is 
Still possible to use them with the overlay 
technique. Called programs that do not 
need to be in main storage at the same time 
can be given the same relative storage 
address and then loaded at different times 
during execution when they are needed. In 
this way, the same storage space can be 
used for more than one called program. 


Considerations for Overlay 


Assume a COBOL main program, called 
COBMAIN, exists that contains calls at one 
Or more points in its logic to COBOL sub- 
programs: CSUB1, CSUB2, CSUB3, CSUB4, and 
CSUB5. Also assume that the load module 
sizes for the main program and the subpro- 
grams are given as follows: 


(“------- qo---------------- ----- --- == 7 
|PROGRAM ]MODULE SIZE (IN BYTES) l 
—------ ‘Scag a agg sag TAB ch asa Ue cca 4 
}COBMAIN | 20, 000 
}cSUB1 | 4, 000 
|CSUB2—| 5, 000 i 
1CSUB3 J 6, 000 
[CSUBG | 3, 000 
1CSUBS | 4, 000 ] 
Legere Maen te eae Pkt est ok ae J 


Through the linkage mechanism, ENTER 
LINKAGE, CALL SUB1..., all subprograms plus 
COBMAIN must be linkage edited together to 
form one module 42,000 bytes in size. 
Therefore, COBMAIN would require 42,000 
bytes of storage in order to be executed. 


If the subprograms needed do not fit 
into main storage, the following two tech- 
niques of overlay are available to the 
COBOL programmer: 


e Preplanned overlay using the linkage 
editor 


e Dynamic overlay using macro instruc- 
tions during execution 


Note: The largest load module that can be 
processed by Fetch is 524,248 bytes. Ifa 
load module exceeds this limit, it should 
be divided. 
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Preplanned Linkage Editing with Overlay 


The preplanned linkage editor facility 
permits the reuse of storage locations 
already occupied. By judiciously segment- 
ing a program and using the preplanned 
linkage editor overlay facility, the pro- 
grammer can accomplish the execution of a 
program too large to fit into storage at 
one time. 


In using the preplanned overlay tech- 
nique, the programmer specifies to the 
linkage editor which subprograms are to 
overlay each other. The subprograms speci- 
fied are processed as part of the program 
by the linkage editor, so they can be auto- 
matically placed in main storage for execu- 
tion when requested by the program. The 
resulting output of the linkage editor is 
called an overlay structure. 


It is possible, at linkage edit time, to 
set up an overlay structure by using the 
COBOL source language statement ENTER 
LINKAGE and the linkage editor OVERLAY 
statement. These statements enable a user 
to call a subprogram that is not actually 
in storage. The details for setting up the 
linkage editor control statements for 
accomplishing this procedure can be found 


System: Linkage Editor, Form C28-6538. 


In a linkage editor run, the programmer 
specifies the overlay points in a program 
by using OVERLAY statements. The linkage 
editor treats the entire input as one pro- 
gram, resolving all symbols and inserting 
tables into the program. 


These tables are used by the control 
program to bring the overlay subprograms 
into storage automatically when called. 


Figure 46 shows the deck arrangement for 
an overlay structure using preplanned 
linkage editor overlay. The OVERLAY state- 
ments specify to the linkage editor that 
the overlay structure to be established is 
one in which SUBPROGA, SUBPROGB, and SUB- 
PROGC overlay each other when called during 
execution. 


Dynamic Overlay Technique 


In preparation for the dynamic overlay 
technique, each part of the program that is 
brought into storage independently should 
be processed separately by the linkage edi- 
tor. (Hence, each part must be processed 
aS a separate load module). To execute the 
entire program, the programmer must: 





SUBPROG C 
OVERLAY ALPHA 


SUBPROG B 
OVERLAY ALPHA 













SUBPROG A 


OVERLAY ALPHA 
INCLUDE SUBRNX 
COBOL MAIN 
PROGRAM 
CARDS 





DD 
EXEC PROGRAM 





Sample Deck for Linkage Editor 
Overlay Structure 


Figure 46. 


1. Specify the main program in the EXEC 
statement, and 


2. Bring the separately processed load 
modules into storage when they are re- 
quired, by using the appropriate 
supervisor linkage macro instructions. 
This is accomplished during execution. 





The dynamic overlay technique can be 
used to overlay subprograms during execu- 
tion. To accomplish dynamic overlay of 
subprograms, the programmer must write an 
assembler language subprogram that employs 
the LINK macro to call each COBOL subpro- 
gram. For a detailed description of the 
LINK macro instruction, refer to the publi- 


cation IBM System/360 Operating System: 
Supervisor and Data Management Macro- 


Instructions, Form C28-6647. 


In using the dynamic overlay technique, 
the main program communicates with the as- 
sembler language subprogram by using the 
COBOL language CALL statement. The COBOL 
CALL statement can be used to pass the name 
of the COBOL subprogram (to be linked) and 
the specified parameter list to the assem- 
bler language subprogram. This procedure 
is effected with each CALL used in the main 
program. Hence, each CALL results in link- 
ing with a subprogram through the assembler 
language subprogranm. 


When the COBOL subprogram is finished 
executing, it returns to the assembler lan- 
guage subprogram, which in turn returns to 
the main program. The process is repeated 
for each CALL to the assembler language 
subprogram. 


This technique requires that a pro- 
grammer have detailed knowledge of the 
linkage conventions, assembler language, 
and the LINK macro with its features and 
restrictions. 


Beyond this, the programmer must ensure 
that the COBOL subprogram modules exist in 
a private library (PDS) and are defined by 
a //JOBLIB DD statement in the job control 
language for execution of the main program. 
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The following topics are discussed in 
this chapter: the data control block, 
error processing for COBOL files, and 
volume and data set labels. 


More information about input/output 
_ processing is contained in the publication 


IBM System/360 Operating System: Supervi- 


sor and Data Management Services, Form 
C28-6646. 


THE DATA CONTROL _BLOCK 


Each data set is described to the 
operating system by a data control block 
(DCB). A data control block consists of a 
group of contiguous fields that provide 
information about the data set to the sys- 
tem for scheduling and executing input/ 
output Operations. The fields describe the 
characteristics of the data set (e.g., data 
set Organization) and its processing 
requirements (e.g., whether the data set is 
to be read or written). The COBOL compiler 
creates a skeleton DCB for each data set 
and inserts pertinent information specified 
in the Environment Division, FD entry, and 
input/output statements in the source pro- 
gram. The DCB for each file is part of the 
object module that is generated. Subse- 
quently, other sources can be used to enter 
information into the data control block 
fields. The process of filling in the data 
control block is completed at execution 
time. 


Additional information that completes 
the DCB at execution time may come from the 
DD statement for the data set and, in cer- 
tain instances, from the data set label 
when the file is opened. 


OVERRIDING DCB FIELDS 


Once a field in the DCB is filled in by 
the COBOL compiler, it cannot be overridden 
by a DD statement or a data set label. For 
example, if the blocking factor for a data 
set is specified in the COBOL source pro- 
gram by the BLOCK CONTAINS clause, it can- 
not be overridden by a DD statement. In 
the same way, information from the DD 
statement cannot be overridden by informa- 
tion included in the data set label. 


ADDITIONAL FILE PROCESSING INFORMATION 


To use an option which is not supported 
by the COBOL (F) compiler, the bit for the 
option in the DCB may be set by calling an 
assembler language subroutine. For 
example, to use the TRACK OVERFLOW feature 
of the System/360 Operating System, the bit 
for the option must be set in the RECFM 
field of the DCB. However, since the conm- 
piler does not support this option and the 
RECFM field contains bits that are set by 
the compiler (including the RECORDING MODE 
bit), this field cannot be overridden by a 
DD statement. The TRACK OVERFLOW bit can 
be set by issuing a CALL instruction (CALL 
SETBIT USING file-name), where SETBIT is an 
assembler language subroutine which sets 
the bit at DCB+36. For information about 
the use of CALL see the chapter "Calling 
and Called Programs" in this publication. 


IDENTIFYING DCB INFORMATION 


The links between the DCB, DD statement, 
data set label, and input/output statements 
are the file-name, the external name in the 
ASSIGN TO clause of the SELECT statement, 
the ddname, and the dsname (see Figure 47). 


1. The file-name specified in the SELECT 
statement and in the FD entry of the 
COBOL source program is the name asso- 
ciated with the DCB. 


2. The external name specified in the 
ASSIGN TO clause of the source program 
is the ddname link to the DD state- 
ment. This name is placed in the DCB. 


3. The dsname specified in the DD state- 
ment is the link to the physical data 
set. 


The fields of the data control block are 
described in the tables in Appendix C. 
They identify those fields for which infor- 
mation must be supplied by the source pro- 
gram, by a DD statement, or by the data set 
label. For further information about the 
data control block, see the discussion of 
the DCB macro instruction for the appropri- 
ate file processing technique in the publi- 


Supervisor_and_ Data Management Services, 


Form C28-6646. 
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| SELECT | 
| Statement | 
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| Input/output 

| Statements | 

bee bee eee J 

Figure 47. Links Between the Select Statement, 
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the DD Statement, the 


Data Set Label, and the Input/Output Statements 


ERROR _ PROCESSING FOR COBOL FILES 
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System_Error Recovery 


During the processing of a COBOL file, 
data transmission to or from an input/ 
output device may not be successful the 
first time it is attempted. If it is not 
successful, standard error recovery rou- 
tines, provided by the operating system, 
attempt to clear the failure and allow the 
program to continue uninterrupted. 


If the error cannot be corrected by the 
system, an abnormal termination (ABEND) of 
the program may Occur unless the programmer 
has specified some means of error analysis. 
Error processing routines initiated by the 
programmer are discussed in the following 
paragraphs. 


DD Statement Option 


For standard sequential files (QSAM), 
the programmer can specify a DD statement 
option which allows continued processing of 
the interrupted file. If the programmer 
has also written an error processing 
declarative section (USE AFTER STANDARD 
ERROR) in his program, the DD statement 
Option is executed when a normal exit is 
taken from the declarative. For further 
information on this DD statement option, 
see the discussion of the EROPT subpar- 
ameter of the DCB parameter in the chapter, 
"Execution Time Data Set Requirements." 


INVALID KEY Option 


Invalid key errors may occur for BISAM 
files, for QISAM files opened as output, 
and for BDAM files. These errors may be 
tested for by means of the INVALID KEY 
clause of the READ, REWRITE, Or WRITE verb. 
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USE AFTER STANDARD ERROR Option 


The programmer may specify the USE 
option in the declarative section of the 
Procedure Division to determine the partic- 
ular cause of the input/output error. With 
the USE AFTER STANDARD ERROR option (Option 
2 of the USE sentence), the programmer can 
pass control to an error processing routine 
to investigate the nature of the error. To 
help find the error condition, this error 
processing routine may include a call to an 
assembler language subroutine. 


For BSAM or QSAM, using an assembler 
language subroutine, the programmer can 
investigate the contents of register 1 to 
determine the type of error and take appro- 
priate action, as for example, returning an 
error code to the main program. 


For the other file processing tech- 
niques, the assembler language subroutine 
can be used to distinguish between invalid 
key and non-invalid key errors. The file- 
name is passed as an argument to the called 
assembler language subroutine. For files 
using the basic file processing techniques 
(BDAM and BISAM) the address of the data 
event control block (DECB) is passed. For 
files using the queued technique (QISAM), 
the address of the data control block (DCB) 
is passed. The DCB or DECB contains at 
least one byte of information describing 
the condition causing the error. With as- 
sembler language instructions, the program 
can interrogate the condition byte, distin- 
guish between KEY and other errors, and 
take appropriate recovery action. Linkage 
to the assembler subroutines can be accomp- 
lished by using the following statements: 


For BSAM or QSAM: 
USE AFTER ERROR ON FILE-A. 


ENTER LINKAGE. 

CALL ‘ERRTNA‘. 
(assembler language) 

ENTER COBOL. 


In this example, ERRTNA is an assembler 
language program used to interrogate the 
contents of register 1. 


USE AFTER ERROR ON FILE-B. 


ENTER LINKAGE. 

CALL *ERRTNB' USING FILE-B. 
(assembler language) 

ENTER COBOL. 


ERRTNB is the assembler language program 
used to investigate the error condition 
byte in the DCB or DECB. 


Appendix G, “Input/Output Error Condi- 
tions," contains a summary of conditions 
causing errors for each processing 
technique. 


Either the INVALID KEY clause or USE 
AFTER STANDARD ERROR declarative, but not 
both, may be specified for a file. If an 
error occurs and neither has been speci- 
fied, the program may terminate abnormally 


execute the USE declarative first and 
then the DD option. 


DD Statement Option: The EROPT sub- 
parameter in the DCB parameter speci- 
fies one of three actions: accept the 
error block, skip the error block, or 
terminate the job. 


USE AFTER STANDARD ERROR: The pro- 
grammer may specify this option in 
order to display the cause of the 
error. Control goes to the declara- 
tive section. The programmer may spe- 
cify a call to an assembler language 
subroutine in the section to examine 
the contents of register 1. The pro- 
grammer can then display a message 
indicating the error and execute his 
DD statement option. 


QISAM 

A. WRITE (load mode): 
Operating System: If the error is un- 
correctable, the program will ABEND 
unless an error processing routine is 


or may continue executing with incorrect specified. 
data. Table 16 lists the error processing 
facilities available for each access 
method. The following discussion sum- 
Marizes the action taken by each facility 


for each method. 


INVALID KEY: If the error is due to an 
invalid key, recovery is possible. 
(The programmer may attempt to recon- 
struct the key and retry the opera- 
tion, Or may bypass the error record.) 

QSAM If the error is not due to an invalid 

Operating System: If the error is un- key, the program terminates. 
correctable (read only), the program 
will ABEND in the absence of a DD sta- 
tement option or USE AFTER STANDARD 
ERROR declarative. If both the DD 
statement option and USE section are 
specified, the control program will 


USE AFTER STANDARD ERROR: Control goes 
to the declarative section. The pro- 
grammer may specify a call to an as- 
sembler language subroutine in the 
section to determine the nature of the 


Table 16. Input/Output Error Processing Facilities 

fer oe Rea ee eee te Te a ee ee ee 1 
| | Error Processing Facility Available | 
| }-------------- qo- ann --=-==- qo nnn nnn nna nnn { 
| | | | COBOL Clauses | 
| | ; | ee ae ; Oe RNa RE Ion { 
| Access ] Operating | DD Statement | |USE AFTER STANDARD | 
j Method | System 1 Option {INVALID KEY | ERROR | 
}--------------------- }-------------- $----------------- ------------ t------------------- { 
| QSAM | X | xX | (1) | md 
|--------------------- 4-------------- 4----------------- 4------------ 4---------=--------- { 
} QISAM WRITE | X | | x | x 
| READ | X | | (1) | X | 
}--------------------- }-------------- 4----------------- }------------ 4---------=--------- { 
| BDAM | x | | x | x | 
}-~-~--~~------------- $-------------- ¢----------------- 4$~----------- }------------------- { 
| BSAM | X | | (1) | X | 
}--------------------- t-------------- 4----------------- }------------ 4------------------- { 
| BISAM | (2) 1 | X | X | 
-—--—-----____.----.-__- Da elie Sil Ss 5 Leaner ey ere Se Leelee FR a ea ea | 


}(1) Error cannot be caused by an invalid key. | 
{ (2) The system standard error recovery facility (SYNAD) is not available. If errors | 
] occur, they are ignored and processing continues with unpredictable results, | 
| unless a programmer-specified error processing routine is included. | 

J 
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error by investigating the DCB. If 
the error is due to a_ key error, 
recovery is possible. If the error is 
not due to a key error, the error is 
uncorrectable. The program may con- 
tinue executing, but processing of the 
file is limited to CLOSE. If the pro- 
grammer closes the file, he may do so 
in either the declarative section or 
in the main body of his program. 


REWRITE (scan mode): 
Same as for WRITE. 


B. READ, 
Operating System: 


INVALID KEY: The error cannot be 
caused by an invalid key. A source 
program coding error is implied and a 
compiler diagnostic message is 
generated. The program is not 
executed. 


USE AFTER STANDARD ERROR: The pro- 
grammer may specify this option in 
order to display the cause of the 
error. Control goes to the declara- 
tive section. The programmer may spe- 
cify a call to an assembler language 
subroutine in the section to determine 
the nature of the error in the DCB. 
Since the error cannot be due to an 
invalid key, processing of the file is 
limited to CLOSE. If the programmer 
elects to close the file, he may do so 
in either the declarative section or 
in the main body of his program. 


BDAM 
Operating System: If the error is un- 
correctable, the program will ABEND 
unless an error processing routine is 
specified. 


INVALID KEY: If the error is due to an 
invalid key, recovery is possible. If 
the error is not due to an invalid 
key, the program terminates. 


USE AFTER STANDARD ERROR: Control goes 
to the declarative section. The pro- 
grammer may specify a call to an as- 
sembler language subroutine in the 
section to determine the nature of the 
error in the DECB. If the error is 
due to a key error or the "no space 


found" condition, recovery is pos- 
sible. Any other error is uncorrect- 
able. The program may continue 


executing, but processing of the file 
is limited to CLOSE. If the pro- 
grammer closes the file, he may do so 
in either the declarative section or 
in the main body of his program. 


BSAM 
Operating System: If the error is un- 
correctable, the program will ABEND 
unless an error processing routine is 
specified. 
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USE AFTER STANDARD ERROR: The pro- 
grammer may specify this option in 
order to display the cause of the 
error. Control goes to the declara- 
tive section. The programmer may 
specify a call to an assembler lan- 
guage subroutine in the section to 
examine the contents of register 1. 
Since the error cannot be due to an 
invalid key, processing of the file is 
limited to CLOSE. If the programmer 
elects to close the file, he may do so 
in either the declarative section or 
in the main body of his program. 


BISAM 
INVALID KEY: If the error is due to an 
invalid key, recovery is possible. If 
the error is not due to an invalid 
key, the error is ignored and process- 
ing of the file continues with un- 
predictable results. 


USE AFTER STANDARD ERROR: Control goes 
to the declarative section. The pro- 
grammer may specify a call to an as- 
sembler language subroutine in the 
section to determine the nature of the 
error. If the error is due to a key 
error or the “no space found" condi- 
tion, recovery is possible. Any other 
error is uncorrectable. In some 
cases, the programmer may wish to 
close the file or he may try to bypass 
the error (see Appendix G). If the 
programmer closes the file, he may do 
so in either the declarative section 
or in the main body of his program. 


VOLUME LABELING 


Various groups of labels may be used in 
secondary storage to identify magnetic tape 
and direct-access volumes, as well as the 
data sets they contain. The labels are 
used to locate the data sets and are iden- 
tified and verified by label processing 
routines of the operating system. 


There are two different kinds of volume 
labels, standard and non-standard. Magnet- 
ic tape volumes can have standard or non- 
standard labels, or they can be unlabeled. 
The type(s) of label processing for tape 
volumes to be supported by an installation 
is selected di ‘ing the system generation 
process. Direct-access volumes are sup- 
ported with standard labels only. 


Standard label support includes the fol- 
lowing label groups: 


A volume label group 


A data set label group for each data 
set 


Optional user label groups, i.e., user 
header and/or trailer labels for 
each data set, for physical 
sequential data set 
organizations. 


Specific information about the contents 
of standard labels is contained in the pub- 


lication IBM System/360 Operating System: 


Supervisor and Data Management Services, 
Form C28-6646. 


STANDARD VOLUME LABELS 


A volume label group is composed of an 
initial volume label and up to seven addi- 
tional volume labels. The initial volume 
label is written by a utility program. 
(For a direct-access volume, this is a 
volume initialization program that is re- 
quired to initialize the volume before it 
can be used for data storage.) 


Additional volume labels are processed 
by installation-written routines. 


The volume label contains a volume seri- 
al number that is used to identify the 
volume. The programmer can request a spe- 
cific volume by specifying its serial 
number in the SER subparameter of the 
VOLUME parameter in the DD statement. The 
volume label is intended primarily to veri- 
fy that the correct volume is mounted. It 
also can be used to prevent use of the 
volume by unauthorized programs. 


DATA SET LABELS 


Data set labels are written when the 
data set is created. The programmer speci- 
fies, in the LABEL parameter of the DD sta- 
tement for the data set, the type of labels 
he wants for the data set. Standard data 
set labels contain installation data (e.g., 
creation date and expiration date), device- 
dependent information (e.g., tape density), 
and information about the characteristics 
of the data set (e.g., record format and 
block length). The DD statement for a data 
set and the program that creates the data 
set are sources of information for its 
label. When a data set is to be retrieved, 
its label type is identified in the LABEL 
parameter of the DD statement. 


MAGNETIC TAPE VOLUME AND DATA SET LABELS 


All standard tape labels (see Figure 48) 
are 80-character records. They are written 
in extended binary~coded-decimal inter- 
change code (EBCDIC) for 9-track tape units 
and in binary-coded-decimal (BCD) for 7- 
track tape units. The tape label is 
recorded in the same density as the data on 
the tape. 


A tape using standard tape labels is 
identified as such by the operating system 
when it reads the initial record and deter- 
mines that it is an initial volume label by 
finding that the first four characters of 
the record are VOL1 (volume label 1). 


Data_Set Header Label Group: The data set 
header label group consists of two data set 
header labels: HDR1 and HDR2. HDR1 con- 
tains operating system data and device- 
dependent information; HDR2 contains data 
set characteristics. (Additional data set 
header labels are not supported.) These 
labels are created by the operating system 
in accordance with a fixed format when the 
data set is recorded on tape. They can 
then be used to locate the data set, to 
verify references to the data set, and to 
protect it from unauthorized use. 


Nonstandard Labels 


The number and contents of nonstandard 
labels can be specified by the user, except 
that the initial record cannot be a stan- 
dard tape volume label; i.e., the first 
four characters of this record cannot be 
voLi. When these first four characters are 
not VOL1, the operating system transfers 
control to the nonstandard label processing 
routines. These routines provide volume 
positioning that is compatible with the 
positioning techniques. used by the system's 
standard label processing routines. The 
operating system assumes that a tape using 
nonstandard labels is properly positioned 
upon completion of a nonstandard label 
processing routine. 


Information concerning use of unlabeled 
volumes, Single data sets in multiple 
volumes, and multiple data sets in multiple 
volumes is contained in the publication IBM 
System/360_ Operating System: Supervisor 


and Data Management Services, Form 
C28-6646. 
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e Figure 48, 


DIRECT-ACCESS VOLUME AND DATA SET LABELS 


All direct-access volume labels are 
written in extended binary-coded-decimal 
interchange code (EBCDIC). 


The format of the direct-access volume 
label group is the same as the format of 
the tape volume label group, except for 
field five of the initial volume label. 


The data set label of a data set ina 
direct-access volume consists of the data 
set control block (DSCB). The DSCB appears 
in the volume table of contents (VTOC) and 
contains the equivalent of the tape data 
set header and trailer information, in 
addition to space allocation and other con- 
trol information. 


j-------------------------- { 
1 2| 
}——~-------- }-------------- { 
| | 3| 
j-----------1-------------- { 
} Additional 4 
-}----------------~---------- 4> Volume Label 
| volume 5|{ Group 
}-------------------------- { 
| Labels 6| 
iia ert CaS fo ee 1 
| | 7| 
}----------- }------+------- { 
1 V 8| 
}-------------------------- { 
| HDR1 | l Data Set 
t-~------------------------ 4( Header Label 
| HDR2 i Group 
}---—~---------------_---__ ; 
| Tape Mark | 
liste aedinc are oe ene ee J 

Data Blocks \ Data Set 
(See Sa Sr SSeS 1 
| Tape Mark | 
}-------------------------- { 
J EOv1 or EOF1 i| Data Set 
p——~—--—--------—---—-----—----- {> Trailer Label 
] EOV2 or EOF2 I( Group 
}---~----------------------4 
J Tape Mark \\ Not End ) End 
}-------------------------- 4/ of Data Sof 
| Tape Mark | Data 
laeceecese ccc ee aaa ae oa J 
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‘is created for the data set, 


Volume Table of Contents 


The volume table of contents (VTOC) con- 
tains data set control blocks that describe 
each data set in that volume. Each data 
set control block (DSCB) contains the 
dsname of the data set and information 
indicating its location in the volume and 
the amount of space allocated to it. The 
dsname of the data set should be unique in 
the volume. If the volume serial number is 
known, the data set can be located in that 
volume. 


The vTOC also contains an indication of 
the amount of space still available in the 
volume. When space is to be allocated for 
a new data set (SPACE, SPLIT, etc.), the 
system checks to see if sufficient space is 
available. If it is, a new data set label 
and the corre- 
sponding VTOC entries are adjusted to 
reflect the decrease in available space. 

If the RLSE subparameter of the SPACE 
parameter has been specified, all unused 
space assigned to the data set is made 
available to the volume when the data set 
is closed. If the disposition KEEP has 
been specified, the data set remains tabu- 
lated in the vTOC after the completion of 
the job. If the disposition catalog has 
been specified, the data set remains tablu- 
lated in the vVTOC and, in addition, an 
entry is made in a system index (see "Cata- 
loging Data Sets" in the chapter “Using the 
DD Statement"). 


When a data set is deleted 
(DISP=(,DELETE)) all references are deleted 
from the VTOC, and the space formerly occu- 
pied by it is made available for other data 
sets. If the data set has been accessed by 
using the system catalog, its name is also 
deleted from the catalog. 


When a data set is uncataloged -- 
DISP=(, UNCATLG) -- however, only the entry 
from the system catalog is removed; the 
data set remains on the volume, and its 
identification remains in the VTOC. 


This chapter contains information con- 
cerning system requirements for the COBOL 
(F) compiler, execution time, and the sort 
feature. Additional information for use in 
estimating the main and auxiliary storage 
requirements is contained in the publica- 


tion IBM System/360 Operating System: 
Storage Estimates, Form C28-6581. 


MINIMUM MACHINE REQUIREMENTS FOR THE COBOL 
(F) LEVEL COMPILER 


The basic system requirements for use of 
the COBOL (F) compiler are: 


e At least a System/360 Model 40, with a 
Minimum of 80K (81,920) bytes of main 
storage available to the compiler, and 
the standard and decimal instruction 
sets. The floating-point instruction 
set is required if floating-point data 
items and fractional exponents are used 
in the program. 


At least 80K (81,920) bytes should 
be allocated in the SIZE option of the 
EXEC job control card that requests 
execution of the compiler. If less 
than this is specified, the system 
assumes the default value of 80K. If 
more storage is allocated, the compiler 
will run more efficiently. 


e A device, such as the 1052 Printer- 
Keyboard, for direct operator 
communication. 


e At least one direct-access device, such 
as an IBM 2311 Disk Storage Drive, for 
residence of the operating system and 
SYSUT1. Both may reside on the same 
volume. 


such as a card reader or a 
for the job input stream. 


e A device, 
tape unit, 


e A printer or tape unit for the system 
output file, unless some other device 
specified for direct operator communi- 
cation is selected at system generation 
time. 


e SYSUT1 on a direct-access device. SYS- 
UT2, SYSUT3, and SYSUT4 can reside on 
tape or on a direct-access device. If 
they reside on a tape device, there 
must be a tape unit for each data set. 
If they reside on a direct-access 
device, there must be enough space in 
the device. 


MACHINE CONSIDERATIONS 


MULTIPROGRAMMING WITH A VARIABLE NUMBER OF 
TASKS (MVT) 


COMPILATION: If the compiler is being 
executed under the MVT control program 
(multiprogramming with a variable number of 
tasks) of the System/360 Operating System, 
the REGION parameter, specified as 86K 
bytes in the COBFC and COBFCLG cataloged 
procedures, becomes significant (see the 
section "Cataloged Procedures"). If the 
programmer wishes to override this value, 
he can specify a region size in either the 
JOB or the EXEC statements of the compiler. 
The size specified should not be less than 
the value of SIZE in the PARM field of the 
EXEC statement, rounded to the next highest 
2K multiple, plus 6K. 


The following examples illustrate both > 
the default and the override cases: 


1. //JOB1 JOB 1234,J3.SMITH 
//STEP1 EXEC COBFC 


In this example, the programmer 
accepts the default value of 86K 
specified in the COBFC cataloged 
procedure. 


2. 4/I30B2 JOB 1234,J.SMITH 
//STEP1 EXEC COBFCLG, REGION=134K, xX 
// PARM. COB=" SIZE=130000!' 


In this example, the default value is 
overridden. Rounding 130000 to the 
next highest 2K multiple, it becomes 
131072, or 128K. Thus, the correct 
region size is 128K+6K=134K. (K=1024 
bytes. ) 


EXECUTION: Priority schedulers require 
that the REGION parameter be specified for 
execution of object programs, unless the 
programmer is willing to accept default 
region size. The default value is 52K 
bytes, and is established in the input 
reader procedure. The region size needed 
for the execution of the object program is 
the sum of the following values: 
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1. The size of the object module after it 
' has been linkage edited with all of 
the necessary object time subroutines. 


2. The size of the input/output buffers 
being used, multiplied by the blocking 
factor (QSAM files are double buffered 
if no blocking factor is specified). 


3. The size of the data management rou- 
tines and control blocks that are used 
(see the publication IBM System/360 
Operating System: 


Se SS eT Ce A ES 


Form C28-6551). 


4. An additional 4K bytes. 


Intermediate Data Sets Under MVT and MFT 


SYSIN and SYSOUT data resides on inter- 
mediate, direct-access, execution-time data 
sets. These data sets are used by the sys- 
tem to temporarily hold all of the job's 
input and output data. The handling of 
SYSIN and SYSOUT data under MVT and MFT 
differs significantly from the handling 
under the primary control program (PCP). 
This is true because the object program 
must use intermediate data sets on direct- 
access devices instead of unit record 
devices. 


SYSIN-SYSOUT_CHARACTERISTICS: The input 
and output data set characteristics are 
determined by the system, but can be 
altered by the programmer if necessary. 
The procedure used to alter the default 
values depends on whether the data set is 
for input or output, as follows: 


e For SYSIN data -- the programmer must 
request, at the time the job is sub- 
mitted, that the operator use one of 
the several reader procedures avail- 
able. Reader procedures are cataloged 
procedures that control the reader and 
vary according to the blocking factor 
specified. 


e For SYSOUT data -- the programmer must 
use override statements as described in 
the section "Cataloged Procedures." 


When a job is being run in an MVT or MFT. 
environment, the SPACE parameter assumes 
added importance. Under the primary con- 
trol program, output goes directly to the 
printer as it is produced; under MVT and 
MFT, output is placed on the SYSOUT inter- 
mediate data set as it is produced. Since 
nothing is written out until the completion 
of the job, the programmer must make sure 
that the SYSOUT data set is large enough to 
hold all of the possible output data of his 
program. The SPACE parameter of the DD 
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statement is specified for SYSOUT with a 
default value of 50 tracks. If the pro- 
grammer determines that his output will 
exceed the default value, he can do either 
or both of two things: 


1. Specify blocking of his data set with 
the DCB parameter of an override DD 
statement 


2. Override the compilation step of a 
compiled procedure by specifying the 
SPACE parameter. An example of a 
statement that can be used is: 


//COB.eSYSPRINT DD SPACE=(121, (500, 50)) 


Note: If the TRK or CYL subparameters of 
the SPACE parameter are used, the pro- 
grammer should be aware that requests will 
differ depending upon the direct-access 
device used (2301, 2303, 2311,...etc.). To 
avoid this consideration, the average- 
record-length subparameter can be used. 


STATEMENTS Under 
the MVT and MFT control programs, input 
data following the DD* or DD DATA card 
becomes a Single data set. Once a CLOSE 
statement is encountered, repositioning 
takes place to the beginning of the data 
set. To avoid errors, the programmer 
should keep this in mind when using more 
than one OPEN and CLOSE statement for a 
data set assigned to SYSIN. 


MULTIPLE OPEN AND CLOSE STATEMENTS: 


Note: Under MVT, a file must be closed 
before the STOP RUN statement is executed. 
Failure to do this will result in an 
abnormal termination. 


EXECUTION TIME CONSIDERATIONS 

The amount of main storage must be suf- 
ficient to accommodate at least: 

e The selected control program 


e Support for the file processing tech- 
nique used 


e Load module to be executed 


The number of input/output devices re- 
quired for the source program is determined 
by whatever is specified in the Environment 
Division. 


SORT FEATURE CONSIDERATIONS 


The basic requirements for use of the 
Sort Feature are: 


e A System/360 model with sufficient main 
storage to accommodate the load module 
to be executed plus a minimum of 15,360 
bytes for the sort program execution. 


e At least one direct-access device 
(which may be the system residence 
device) for residence of SYS1.SORTLIB. 


e At least three tape units or one 
direct-access device for intermediate 
storage. 
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The following is a sample COBOL program 
and the output listing resulting from its 
compilation, linkage editing, and execu- 
tion. The program creates a blocked, unla- 
beled, standard sequential file, writes it 
out on tape, and then reads it back in. It 
also does a check on the field called NOo- 
OF-DEPENDENTS. All data records in the 
file are displayed. Those with a zero in 
the NO-OF-DEPENDENTS field are displayed 
with the special character Z. The records 
of the file are not altered from the time 


//S5QB3 JOB 
//STEP3 EXEC 
//SYSUTL DD 
//SYSUT2 OD 
//SYSUT3 DD 
//SYSUT4 DD 
//SYSLIN DD 
// DISP=(NEW,PASS) 
//SYSPRINT OD SYSOQUT=A 


PROGRAMMERNAME , MSGLEVEL=1 


//SYSIN DD Ea 
TEF2361 ALLOC. FOR JOB3 


STEP3 
ON 190 
ON 190 
ON 190 
ON 190 
ON 190 
ON 0OC 


TEF2371 SYSUT1 
IEF2371 SYSUT2 
IEF2371. SYSUT3 
IEF2371 SYSUT4 
IEF2371I SYSLIN 
IEF2371 SYSIN 


APPENDIX A: SAMPLE PROGRAM OUTPUT 


of creation, despite the fact that the NO- 
OF-DEPENDENTS field is changed for display 
purposes. The individual records of the 
file are created using the subscripting 
technique. TRACE is used as a debugging 
aid during program execution. 


The chapter "Output" describes the out- 
put formats illustrated in the listing. 
The parts of the listing are numbered in 
accordance with the numbers used in the 
chapter "Output." 


PGM=ITEQCBLOO, PARM= * BUF=13000, SIZE=160000, MAP * 
DSNAME=8UT1,;,UNIT=SYSDA,SPACE=(TRK,(100,10)) 
DSNAME=6UT2,UNIT=SYSDA; SPACE=(TRK, (100,10) ) 
DSNAME=6UT3;UNIT=SYSDA;SPACE=(TRK, (100,10) } 
DSNAME=8UT4,UNIT=SYSDA,SPACE=( TRKy (100,10) ) 
DSNAME=PUNCH, UNIT=SYSDA,SPACE=(TRKy(100,10)); 
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100010 IDENTIFICATION DIVISION. 

100020 PROGRAM-ID. ‘TESTRUN'. 

100030 AUTHOR. PROGRAMMER NAME. 

100040 INSTALLATION. NEW YORK PROGRAMMING CENTER. 

100050 DATE-WRITTEN. MAY 31 1966. 

100060 DATE-COMPILED. NOV 2,1966 

100070 REMARKS. THIS PROGRAM HAS BEEN WRITTEN AS A SAMPLE PROGRAM FOR 
100080 COBOL USERS. IT CREATES AN OUTPUT FILE AND READS IT BACK AS 
100090 INPUT. 

100100 ENVIRONMENT OIVISION. 

100110 CONFIGURATION SECTION. 

100120 SOURCE~COMPUTER. IBM~-360 E50. 

100130 OBJECT-COMPUTER. IBM-360 E50. 

100140 INPUT-OUTPUT SECTION. 

100150 FILE-CONTROL. 

100160 SELECT FILE-1 ASSIGN TO *SAMPLE* UTILITY. 

100170 SELECT FILE~2 ASSIGN TO *SAMPLE* UTILITY. 

100180 DATA DIVISION. 

100190 FILE SECTION. 

100200 FD FILE=~1 

100210 LABEL RECORDS ARE OMITTED 

100220 BLOCK CONTAINS 100 CHARACTERS 

100230 RECORDING MODE IS F 

100240 DATA RECORD IS RECORD-1. 

100250 01 RECORD~-1. 

100260 O02 FIELD-A PICTURE IS X(20). 

100270 FD FILE~2 

100280 LABEL RECORDS ARE OMITTED 

100290 BLOCK CONTAINS 5 RECORDS 

100300 RECORD CONTAINS 20 CHARACTERS 

100310 RECORDING MODE IS F 

100320 DATA RECORD IS RECORD-2. 

100330 01 RECORD-2. 

100340 O02 FIELD-A PICTURE IS X(20). 

100350 WORKING~STORAGE SECTION. 

100360 77 COUNT PICTURE S99 COMPUTATIONAL. 

100370 77 ALPHABET PICTURE X(26) VALUE IS *ABCDEFGHIJKLMNOPQRSTUVWX 
100380- "YZ". 

100390 77 ALPHA REDEFINES ALPHABET PICTURE X OCCURS 26 TIMES. 
100400 77 NUMBER) PICTURE S99 COMPUTATIONAL. 

100410 77 DEPENDENTS PICTURE X(26) VALUE IS '012340123401234012340 
100420- *12340', 

100430 77 DEPEND REDEFINES DEPENDENTS PICTURE X OCCURS 26 TIMES. 
100440 O01 WORK-RECORD. 

100450 NAME-FIELD PICTURE X. 

100460 FILLER PICTURE X VALUE SPACE. 

100470 RECORD-NO PICTURE 9999. 

100480 FILLER PICTURE X VALUE SPACE. 

100490 LOCATION PICTURE AAA VALUE 'NYC*.- 

100500 FILLER PICTURE X VALUE SPACE. 

100510 NO-OF=DEPENDENTS PICTURE XX. 

100520 FILLER PICTURE X(7) VALUE SPACES. 

100530 PROCEDURE DIVISION. 

100540 BEGIN. READY TRACE. 

100550 NOTE THAT THE FOLLOWING OPENS THE OUTPUT FILE TO BE CREATED 
100560 AND INITIALIZES COUNTERS. 

100570 STEP-1. OPEN OUTPUT FILE~1. MOVE ZERO TO COUNT; NUMBER. 

100580 NOTE THAT THE FOLLOWING CREATES INTERNALLY THE RECORDS TO BE 
100590 CONTAINED IN THE FILEs WRITES THEM ON TAPE; AND DISPLAYS 
100600 THEM ON THE CONSOLE. 

100610 STEP~-2. ADD 1 TO COUNT; ADD 1 TO NUMBER: MOVE ALPHA (COUNT) TO 
100620 NAME-FIELD. 

100630 MOVE DEPEND (COUNT) TO NO-OF-DEPENDENTS. 

100640 MOVE NUMBER TO RECORD-NO. 

100650 STEP-3. DISPLAY WORK-RECORD UPON CONSOLE. WRITE RECORD-1 FROM 
100660 WORK-RECORD. 

100670 STEP-4. PERFORM STEP-2 THRU STEP=-3 UNTIL COUNT IS EQUAL TO 26. 
100680 NOTE THAT THE FOLLOWING CLOSES OUTPUT AND REOPENS IT AS 
100690 INPUT. 

100700 STEP-5. CLOSE FILE~1. OPEN INPUT FILE-2. 

100710 NOTE THAT THE FOLLOWING READS BACK THE FILE AND SINGLES OUT 
100720 EMPLOYEES WITH NO DEPENDENTS. 

100730 STEP-6. READ FILE-2 RECORD INTO WORK-RECORD AT END GO TO STEP-8. 
100740. STEP-7. IF NO-OF-DEPENDENTS IS EQUAL TO 'O' MOVE 'Z* TO 

100750 NO-OF-DEPENDENTS. EXHIBIT NAMED WORK-RECORD. GO TO 
100760 STEP~6. 

100770 STEP-8. CLOSE FILE-2 . 

100780 STOP RUN. 
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00358 (LIT+0) 


@® 


INTRNL NAME 


DNM=1-354 


DNM=2~-000 

























® © 


LVL SOURCE NAME 

DNM=1-146 FD FILE-1 
. DNM=1~-164 Ol RECORD-1 

DNM=1~184 02 FIELD-A 
DNM=1~-200 FD FILE-2 
ONM=1~-218 Ol RECORD~2 
DNM=1-238 02 FIELD-A 
DONM=1-257 77 COUNT 
ONM=1-271 77 ALPHABET 
ONM=1-288 77 ALPHA 
DNM=1~305 77 NUMBER 
DNM=1~-320 77 DEPENDENTS 
DNM=1-339 77 DEPEND 

01 WORK-RECORD 
ONM=1=-377 02 NAME~FIELD 
DNM=1~396 02 FILLER 
DNM=1~-411 02 RECORD~NO 
DNM=1-429 02 FILLER 
DNM=1~447 02 LOCATION 
DNM=1-464 02 FILLER 
DNM=1-482 02 NO-OF-DEPENDENTS 


02 FILLER 





@® MEMORY MAP 


LITERAL POOL (HEX) 


DISPLAY LITERALS (BCD) 


00364 (LTL+12) 


REG 6 
REG 7 








BASE 
OCB=01 
BLI=1 
BLI=1 
DCB=02 
BLI=2 
BLI=2 
BLI=3 
BLI=3 
BLI=3 
BLI=3 
BLI=3 
BLI=3 
BLI=3 
BLI=3 
BLI=3 
BLI=3 
BLI=3 
BLI=3 
BLI=3 
BLI=3 
BLI=3 


TGT 00160 
SAVE AREA 00160 
SWITCH CELL 001A8 
TALLY CELL OO1AC 
UNUSED 001B0 
ENTRY~SAVE 00188 
UNUSED 001BC 
WORKING CELLS 001C0 
GVERFLGW CELLS 002FO 
TEMPORARY STOKAGE CELLS 002FO 
TEMPORARY STORAGE-2 CELLS 002F8 
BLL CELLS 002F8 
SBL~I CELLS 002F8 
BL-I CELLS 002F8 
SUBADR~I CELLS 00304 
ONCTL~1I CELLS 00304 
PFMCTL~I CELLS 00304 
PFMSAV-I CELLS 00304 
VN=I CELLS 00308 
DECBADK-I CELLS 0030C 
SAVE AREA =2 0030C 
SAVE AREA =3 0030C 
XSASW-I CELLS 0030C 
XSA-I CELLS 0030C 
PARAM CELLS 0030C 
RPTSAV AREA 00314 

00000001 OOLAFOE9 Co000000 
*WORK-RECORD! 

PGT 00318 
OVERFLOW CELLS 00318 
VIRTUAL CELLS 00318 
PROCEDURE NAME CELLS 0031C 
GENERATED NAME CELLS 00330 
OCB ADDRESS CELLS 00348 
VNI CELLS 00350 
LITERALS 00358 
DISPLAY LITERALS 00364 


REGISTER ASSIGNMENT 


BLI=3 
BLI=1 


Q® © 


DISPL 





000 
000 


000 
000 
000 
002 
002 
o1c 
OLE 
O1E 
038 
038 
039 
03A 
O3E 
O3F 
042 
043 
045 








© 


INTRNL NAME 


ONM=1~-146 
DNM=1-164 
ONM=1-184 
ONM=1~200 
ONM=1-218 
ONM=1-238 
DONM=1-257 
ONM=1-271 
DNM=1-288 
ONM=1-305 
DNM=1-320 
DNM=1-339 
DNM=1-354 
ONM=1-377 
ONM=1~-396 
DNM=1-411 
ONM=1-429 
ONM=1~447 
DONM=1-464 
ONM=1~482 
DNM=2~-000 








© 





DEFINITION USAGE 
QSAM 

DS OCL20 GROUP 

DS 20C DISP 
QSAM 

DS OCL20 GROUP 

DS 20C DISP 

DS 1H COMP 

DS 26C DISP 

DS 1C DISP * # 

DS 1H COMP 

DS 26C DISP 

DS 1C DISP * 

DS OCL20 GROUP 

DS 1C DISP 

DS 1C DISP 

DS 4C DISP-NM 

DS 1C DISP 

DS 3C DISP 

DS 1C DISP 

DS 2C DISP 


DS 


Appendix A: 


Sample Program Output 


167 


168 


REG 8 


54 


BLI=2 


(8) 
*BEGIN 


READY 
*STEP-1 


MOVE 


¥*STEP-—2 


¥*STEP-3 


© 


000370 
000370 
000374 
000376 
000379 
000380 


000384 
000388 
00038A 
00038) 
000394 
000398 
00039C 
0003A0 
0003A4 
0003A6 
OOO3AA 
OOO3AE 
000380 
000384 
000388 
OOO3BE 


0003C4 
0003C4 
0003C8 
0003CA 
0003CD 
000304 
0003D8 
00030C 
0003E0 
0003E4 
0003E8 
0003EC 
6003F0 
0003F4 
0003F8 
0003FA 
0003FE 
000404 
000408 
00040C 
000410 
000412 
000416 
00041C 
000420 


000424 
000428 
00042E 


000432 
000436 
0004338 
00043B 


© 


58 FO C 000 
05 1F 

000140 
04C2C5C 70905 
96 40 D 048 


58 FO C 000 
05 1F 
000140 
O5E2E3C50760F 1 
C 030 
D 1AC 
D 1AC 
D 1AC 
030 
030 


198 
198 
000 C 040 
01C C 040 


58 FO C 000 

05 1F 

000140 

05E 2E3C 5D760F2 
48 C 042 

4A "000 

40 000 

48 042 

4A O1Cc 

40 oO1c 

41 002 

48 000 

4C 042 

1A 
5B 040 
038 
OLE 
000 
042 


ARAAAaAN OAenroaannen 


040 
043 
044 
o1c 
190 
O3A 
03D 


aooconcnanannd 


a 


000 


060140 
O5EZE3C5D760F3 


* 

15,000(0,12) 
1,15 

X*000140° 
X*04C2C5C7C9D5* 
048(13)4X'40* 


15,000(0,12) 
1,15 

X*000140! 
X"O5E2E3C 5D760F1° 
1,030(0,12) 
1,1AC(0,13) 
1AC(13),X*8F* 
1,1AC(0,13) 

19 

1,030(0,12) 
15,030(0,1) 
14,15 
1,198(0;13) 
7,198(0,13) 
000(2;6),040(12) 
010 (226) 040(12) 


* 

15,000(0,12) 
1,15 

X*0001408 
X*05E2E3C 507 60F2* 
3+042(0,12) 
3,000(036) 
3,000(0;6) 
3+042(0;,12) 
3,01C(0,6) 
3,301C(0,6) 
4,002(0%6) 
2:000(0;6) 
21042(0;12) 

432 

4:040(0,12) 
038(1,6),000(4) 
2201E(0,6) 
1,000(0,6) 
1,042(0712) 

21 

21040(0;12) 
043(1,6),000(2) 
044(6)sX"40!8 
3701C(0,6) 
3,190(0,13) 
03A(4,6),196(2,13) 
03D(6) »X*FO® 


15,000(0,12) 

1,15 

X*000140! 
X*O5E2E3C5D760F3* 


@ 


VC THDFDISP) 


SWT+0 


VC THDFDISP) 


DCB=1 
PRM=1 
PRM=1 
PRM=1 


DCB=1 


BLI=1 
BLI=1 
DN4=1-257 
DNM=1-305 


VCITHDFOISP) 


LIT+2 
DNM=1-257 
ONM=1-257 
LIT+2 
ONM=1~-305 
ONY=1-305 
DNM=1-288 
DNM=1-257 
LIT+2 


LIT+0 
DNM=1-377 
DNM=1-339 
DNM=1-257 
LIT+2 


LIT+0 
DNM=1-482 
DNM=1-482+1 
DNM=1-305 
TS=01 
DNM=1-411 
DNY=1-411+3 


VCTHDFDISP) 





LY 





65 


67 


67 


70 


70 


DISPLAY 


WRITE 


*¥STEP 4 


PERFORM 


¥*STEP—-5 


CLOSE 


© 


000442 
000446 
000448 
600444 
000448 
00044E 
000452 
000454 
000456 
00045C 
000460 
000464 
000466 
00046A 
00046E 
00046E 
000472 


000474 
000474 
000478 
00047A 
00047) 
000484 
000488 
00048C 
000490 
000494 
000494 
000498 
00049C 
0004A0 
Q004A2 
GO04A6 
0004A8 
0004A3 
OO004AC 


000480 
0004B4 
0004B6 
0004B9 
0004CO 
0004C4 
co04C8 
0004CC 
OO04CE 
0004D2 
0004D6 
0004DA 
OGO4DE 
O0004E2 
0004E6 
OOO4EA 
OOQ4EE 
0004FO 
QQ04F4 
O004F8 
0004FC 
000500 


© 


58 FO C 000 
05 1F 

0002 

00 

000014 
ODO001A0 
0038 

FRFF 

D2 13 7 000 
58 10 C 030 
58 FO 1 030 
05 EF 

50 10 D 198 
58 70 D 198 


58 10 D 1A8 
O7 Fl 


58 FO C 000 
05 1F 
000140 


6 038 


O5E2E3C5D760F4 


58 00 D 1A8 
50 00 U 1A4 
58 00 C 01C 
50 00 D 1A8 


000 
044 
020 


48 30 
49 30 
58 FO 
O7 8F 
58 10 C 004 
O7 Fl 


aoe 


58 00 D 1A4 
50 00 D 1A8 


58 FO C 000 
05 1F 
000140 


O5E2E3C5D760F5 


58 10 C 030 
58 20 1 O02C 
91 OF 2 00C 
05 50 
47 EO 
58 20 
4B 20 
50 20 
58 10 
50 10 


010 
04C 
052 
04C 
030 
1AC 
LAC 
LAC 


(on we 3 Os ee Oe 


030 
014 
017 
004 
006 


ve) 

o 

oO 

~ 
rPeNNO 


GN=01 


PN=02 


GN=02 


GN=03 


EQU 
BALR 
oc 
ST 


ST 
EQU 


CH 
BCR 


BCR 
EQU 


ST 


BALR 


oc 


™ 
BALR 


Appendix A: 


15,000(0,12) 
1,15 

x'o00028 
x*0o" 
X*000014! 
X*ODOGOLAOC! 
Xx*0038! 
X*FFFF® 
000(20,7) ,038(6) 
1,030(0;12) 
15,030(0,1) 
14,15 
1,198(0,13) 
73198(0,13) 
x 
1,1A8(0;13) 
15,1 


* 
15,000(0,12) 

1,15 

X*000140" 
X*O5E2E3C5D760F4* 
0,1A8(0,13) 
0,1A4(0,13) 
0,01C(0,12) 
0,1A8(0,13) 

* 

3,000(0,6) 
34044(0,12) 
15:020(0,12) 

8,15 

1,004(0,12) 

15:1 

* 

0+1A4(0,13) 
0+1A8(0,13) 


15 ,000(0,12) 
1,15 
X*000140! 
X*O5E2E3C5D760F 5° 
1,030(0,12) 
2,02C(0;1) 
OOC(2) »X'OF* 
5,0 
14,010(0,5) 
2704C(0,1) 
21052(0,1) 
2204C(0,1) 
1,030(0,12) 
1,1AC (0,13) 
1AC(13),X*90! 
1,1AC(0,13) 
20 
21030(0,12) 
1,014(0,2) 
017(2),xX'Ol1* 
4,004(0;1) 
4,006(051) 


© 


VC ITHDFDISP} 


BLI=3 


DNM=1~-164 
DCB=1 


BLI=1 
BLI=1 


VN=01 
VCTHDFOISP) 


VN=01 
PSV=1 
GN=02 
VN=01 


DNM=1-257 
LIT+4 
GN=03 
PN=0O1 
PSV=1 
VN=01 


VC THDFDISP) 


DCB=1 


DCB=1 
PRM=1 
PRM=1 
PRM=1 


DCB=1 


DNM=1-354 
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70 


%3 


73 


73 


14 


74 


74 


75 


® © 


OPEN 


*STEP=6 


Rt Av 


GU 


*STEP-7 


IF 


MUVE 


EaHIBIT 


© 


000504 
600508 
00050C 
OCO50E 
000512 
600516 
OCOSLA 
COO5ir 


000520 
000520 
600524 
000526 
000529 
G00530 
000534 
OGODSA 
00053e 
060540 
000544 
000543 
OO054E 
000552 
000554 
000554 
000558 


G0055A 
00055A 
00055 
600560 
000563 
00056A 
00056E 
000572 
000578 
00057A 
O0057E 
000580 
000580 
000586 
00058A 
00058A 
GOO58E 
000592 
000596 
OGO59A 
00059C 
00059E 
00059F 
0005A2 
0005A6 
O005A8 
0005A9 
OOO5AC 
000580 
0005B2 


© 


41 00 4 008 
41 10 1 000 
OA GA 

58 10 C 034 
50 10 D 1AC 
92 80 D 1AC 
41 10 D 1AC 
OA 13 


58 FU C v00 

o5 1F 

G00140 
O5EZESC5UT60Fe 

58 10 C 034 

b2 02 1 021 C 025 
58 FO 1 030 


05 EF 

50 10 D 19C 

58 80 UD 19C 

b2 13 6 038 8 G00 
58 10 C 010 

OT Fl 

58 10 C 014 

oT Fl 

58 FO C 000 

Q5 1F 

000140 
O5E2E3C5U760F7 
58 10 C 02C 

58 20 C 028 

D5 6G C 046 6 043 
OT 72 

95 40 6 044 

O7 72 

D2 00 6 643 C 047 
92 4U 6 044 

58 10 C 048 

50 10 D LAC 

41 20 D 1AC 

58 FO C 000 

05 1F 

‘6001 

10 

000008 
ocO0004C 

0000 

00 

000014 
000001A0 

0038 

FFFR 


© 


PN=03 


GN=04 


PN=04 


GN=06 


GN=05 


LA 
LA 
Svc 
ST 
MVI 
LA 
SVC 
EQU 
BALR 
OC 
MVC 


BALR 
ST 


MVC 


BCR 
EQU 


BCR 


EQU 


© 


0,008(0,4) 
1,000(0,1) 

10 
1,034(0,12) 
1,1AC(0,13) 
1AC(13),X*"808 
1,1AC(0,13) 
19 


* 

15,000(0;12) 
1,15 

X*000140! 
X*O5E2E3C5D760F 6! 
1:034(0,12) 
021(341),025(12) 
15,030(0,1) 
14,15 
1,19C(0,13) 
8,19C(0,13) 

038 (20,6) ,000(8) 
1,010(0,12) 

1591 

* 


1,014(0,12) 
1591 


* 

15,000{0,12) 
1,15 

X*000140! 
X*O5E2E3C5D0760F7*# 
1,02C(0,12) 
22028(0,12) 
046(1,12) .043(6) 
W312 

044(6),X"408 

712 

x* 

043(1,6) 047(12) 
044(6)+X"408 

* 


1,048(0,12) 
1,LAC (0913) 
211AC(0,13) 
15,000(0,12) 
1,15 
x*8001' 
X*10! 
X*QOO00B* 
X'0CO00004C* 
X*00004 
x*oo* 
X*000014! 
X*OD0001A0' 
X'0038! 
X'FFFFS 


© 


DCB=2 
PRM=1 
PRM=1 
PRM=1 


VCIHDFDISP) 
OCB=2 


BLI=2 
BLI=2 
DNM=1-354 
PN=04 


PN=05 
V(IHOFDISP) 


GN=06 
GN=05 
LIT+6 


DNM=1~48 2+1 
DNM=1-482 
DNM=1-482+1 
LIT+8 

PRM=1 


PRM=1 
VC THOFDI SP} 


LIT+12 


BLI=3 


GN=04+1 


DNM=1-218 


DNM=1~-482 


LIT+7 


© © © © 


GO 0005B4 58 10 C OOC 1,00C(0412) 
000588 07 Fl 15,1 

*STEP-8 
0005BA * 
0005BA 58 FO C 000 15,000(0,12) VC EHDFDISP) 
O005BE 05 1F 1,15 
0005CO 000140 X*0001408 
0005C3 05E2E3C5D760F8 X*05€2E3C5D760F 8! 
0005CA 034 11034(0;12) 
0005CE 02c 2402C(0,1) 
0005D2 00c 00C(2),X*0F* 
000506 540 
000508 010 14,010(0;5) 
00050C 04C 2104C(091) 
0005E0 052 24052(0,1) 
0005E4 O4C 2104C(091) 
0005E8 034 1,034(0,12) 
OO05EC LAC 1,1AC( 0413) 
0005FO 1AC 1AC(13);X*908 
0005F4 LAC 1,1AC(0,13) 
0005F8 20 
OOO5FA 034 21034(0,12) 
OOO5FE 014 14014(042) 
000602 017 017(2),X*018 
000606 004 41004(0,1) 
00060A 006 4006(0,1) 
00060E 008 01008(0,4) 
000612 1,000(091) 
000616 10 
000618 13,004(0,13) 
00061¢ 1412,00C(13) 
000620 15,15 
000622 15414 
000624 . 13,008(0,5) 
000628 5+004(0,13) 
00062C 14,054(0113) 
000630 9. 048(13),X*20! 
000634 149 
000636 048(13) +X"20! 
00063A 41 ¢ 6100410,0) 
00063E . 12004(0,12) 
000642 71040(0,12) 
000646 710 
000648 540 
00064A 5 41000091) 
00064E 411 
000650 41000(0,1) 
000654 116,000(5) 
000658 198 8+198(0,13) 
00065C 003 7 1003(040) 
000660 1,0 
000662 000 07000(078) 
000666 Orll 
000668 8 000 0 1000(0,8) 
00066 004 8 1004(028) 
000670 06 751 
000672 1A8 C 038 INIT3 1A8 (4,13) 7038(12) 
000678 LAO 61A0(0;13) 
00067C 198 74198(0913) 
000680 19 8119 (0213) 
000684 15,14 
000000 0+0 
000002 00c 14412,00C(13) 
000006 5413 
000008 1540 
00000A F 006 91151006(15) 
00000E 15915 
000010 00000672 L4(INIT3) 
000014 00000000 L4(EXITR) 
000018 00000000 L4CINITL) 
00001C 00000318 L4( PGT) 
000020 00000160 L4(TGT) 
000024 00000370 L4(START) 
000028 00000624 L4(INIT2) 
00002C 96 12 1 034 034(1),X#12# 
000030 O07 FE 15414 
000032 FFFFFFFF X" FFFFFFFF* 
000036 E3C5E2E3D9E4D540 X"E3C5E2E3D9E4D540° 


em Pee NO OUD CONF KrYEw NEO 


O00 
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® © © © 


j ) CARD ERROR MESSAGE 
17 IEQ1080I-W PERIOD PRECEDED BY SPACE. ASSUME END OF SENTENCE. 


IEF2851 UT1.J0B3 DELETED 
IEF2851 VOL SER NOS= 111111. 

IEF2851 UT2.J0B3 DELETED 
IEF2851 VOL SER NOS= 111111. 

IEF2851 UT3.J0B3 DELETED 

IEF2851 VOlt SER NOS= 111111. 

IEF285I1 UT4.J0B3 DELETED 
IEF2851 VOL SER NOS= 111111. 

IEF2851 PUNCH PASSED 
IEF285I1 VOL SER NOS= 111111. 

IEF2851 SYSOUT SYSOUT 
LEF2851 VOL SER NOS= SCRTCH, 

J/STEP4 EXEC PGM=IEWL,PARM='XPFF? 

//SYSUT1 DD DSNAME=6UT1,UNIT=SYSDA,SPACE=(TRK» (100,10) ) 
/7SYSLMOD DD DSNAME=GOJ0B(GO) »,UNIT=SYSDA, SPACE=(TRKs(100,1091)), 
AS DISP=(NEW, PASS) 

//SYSLIB OD DSNAME=SYS1.COBLIB,DISP=OLD 

7/SYSPRINT DD SYSOUT=A 

//SYSLIN DD DSNAME=PUNCHsUNIT=SYSDAsSPACE=(TRK,(100,10)), 
4/ DISP=(OLD,DELETE) 

IEF2361I ALLOC. FOR JOB3 STEP4 

IEF2371 SYSUT1 ON 190 

IEF2371 SYSLMOD ON 190 
| reF2371 SYSLIB ON 190 

IEF2371 SYSLIN ON 190 


E-LEVEL LINKAGE EDITOR OPTIONS SPECIFIED--XREF 
(4) 1EWoo00 ~—s-sGo NOW ADDED TO DATA SET 


~-~-~ CROSS REFERENCE TABLE ---- 


CONTROL SECTION ENTRY 


NAME ORIGIN LENGTH NAME LOCATION NAME LOCATION NAME LOCATION NAME LOCATION 


TESTRUN 00 6AC 
IHDFDISP« 6B0 58C 


©{ LOCATION REFERS TO SYMBOL IN CONTROL SECTION 
330 IHDFOISP IHDFDISP 


© ENTRY ADDRESS 
TOTAL LENGTH 
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IEF285I UT1.J083 DELETED 
IEF2851 VOL SER NOS= 111111. 

IEF2851 GOJOB PASSED 
TEF285I VOL SER NOS= 111111. 

IEF2851 SYS1.COBLIB KEPT 
IEF285I VOL SER NOS= 111111. 

IEF285I SYSOUT SYSOUT 
IEF285I1 VOL SER NOS= SCRTCH. 

IEF2851 PUNCH DELETED 
IEF2851 VOL SER NOS= 111111. 

7/STEPS EXEC PGM=*.STEP4.SYSLMOD 

//SYSOUT DD SYSOUT=A 

7/SYSABEND DD SYSOUT=A 

//SAMPLE DOD UNIT=2400,LABEL=(,NL) 

IEF236I ALLOC. FOR JOB3 STEPS 

IEF2371 PGM=*.DD ON 190 

IEF237I SAMPLE ON 282 


STEP=1 
STEP-2 
STEP-3 
STEP-4 
STEP-2 
STEP-3 
STEP-2 
STEP-3 
STEP~2 
STEP~3 
STEP=2 
STEP=3 
STEP-2 
STEP-3 
STEP-2 
STEP=3 
STEP-2 
STEP-3 
STEP~2 
STEP-3 
STEP-2 
STEP=3 
STEP~2 
STEP-3 
STEP=2 
STEP-3 
STEP-2 
STEP-3 
STEP=2 
STEP-3 
STEP-2 
STEP-3 
STEP=2 
STEP-3 
STEP-2 
STEP-3 
STEP-2 
STEP-3 
STEP-2 
STEP~3 
STEP-2 
STEP-3 
STEP~2 
STEP~3 
STEP~2 
STEP=3 
STEP~2 
STEP-3 
STEP~2 
STEP-3 
STEP-2 
STEP~3 
STEP=2 
STEP~3 
STEP=5 
STEP~6 
STEP-7 
WORK-RECORD = A 0001 NYC Z 
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STEP-6 
STEP-7 
WORK-RECORD 
STEP-6 
STEP-7 
WORK-RECORD 
STEP-6 
STEP~7 
WORK-RECORD 
STEP~6 
STEP~7 
WORK-RECORD 
STEP6 
STEP-7 
WORK-RECORD 
STEP-6 
STEP~7 
WORK-RECORD 
STEP-6 
STEP-7 
WORK~RECORD 
STEP-6 
STEP~7 
WORK-RECORD 
STEP-6 
STEP-7 
WORK-RECORD 
STEP-6 
STEP-7 
WORK-RECORD 
STEP-6 
STEP~7 
WORK-RECORD 
STEP-6 
STEP~7 
WORK-RECORD 
STEP-6 
STEP-7 
WORK-RECORD 
STEP-6 
STEP-7 
WORK~RECORD 
STEP=6 
STEP-7 
WORK-RECORD 
STEP=6 
STEP~7 
WORK-RECORD 
STEP-6 
STEP=7 
WORK-RECORD 
STEP-6 
STEP~7 
WORK-RECORD 
STEP~6 
STEP-7 
WORK-RECORD 
STEP-6 
STEP-7 
WORK-RECORD 
STEP=6 
STEP-7 
WORK-RECORD 
STEP-6 
STEP-7 
WORK-RECORD 
STEP=6 
STEP-7 
WORK-RECORD 
STEP~6 
STEP-7 
WORK-RECORD 
STEP-6 
STEP-7 
WORK-RECORD 
STEP-6 
STEP-8 





IEF285I GOJOB PASSED 
IEF2851 VOL SER NOS= 111111. 

IEF285I1 SYSOQUT SYSOUT 
TEF2851 VOL SER NOS= 

IEF2851 SYSOUT SYSOUT 
TEF2851 VOL SER NOS= ° 

{EF2851 AAAAAAAA’AAAAAAAA« AAAAAAAA.’ AAAAAAAA2j 00000008 DELETED 
TEF2851 VOL SER NOS= LGLOO1. 

IEF285I GOJOB DELETED 
IEF2851 VOL SER NOS= 111111. 


START RDR,OOC 
START 

IEC1O1A M 283, 
0001 NYC 
0002 NYC 
0003 NYC 
0004 NYC 
0005 NYC 
0006 NYC 
0007 NYC 
0008- NYC 
0009 NYC 
0010 NYC 
0011 NYC 
0012 NYC 
0013 NYC 
0014 NYC 
0015 NYC 
0016 NYC 
0017 NYC 
0018 NYC 
0019 NYC 
0020 NYC 
0021 NYC 
0022 NYC 
0023 NYC 
0024 NYC 
0025 NYC 
0026 NYC 
IEF101I RDR CLOSED 
IEEOO7A READY. 


OfuUROFWHNORFPOFTWNRPOFWNHROFTWNHH SO 


A 
B 
c 
D 
E 
F 
G 
H 
I 
J 
K 
L 
M 
N 
0 
P 
Q 
R 
S 
7 
U 
Vv 
W 
x 
Y 
Z 
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COBOL library subroutines perform opera- 
tions requiring such extensive codes that 
it would be inefficient to place them in 
the object module each time they are 
needed. 


COBOL library subroutines are stored in 
the COBOL (F) library (SYS1.COBLIB). The 
required subroutines are inserted in load 
modules by the linkage editor. 


There are five major categories of COBOL 
library subroutines: 


e Conversion routines 


e Arithmetic verb routines 

e Input/output verb routines 

e Sort feature interface routines 
e Other verb routines 


In addition, Q routines, which are not 
classified as COBOL library subroutines, 
are used to calculate the length of 
variable-length fields and the location of 
variably-located fields resulting from an 
OCCURS DEPENDING ON clause. They are 
stored in the Task or Subtask Global Tables 
in the object module. 


COBOL LIBRARY CONVERSION SUBROUTINES 


Eight numeric data formats are permitted 
in COBOL; five external (for input and out- 
put) and three internal (for internal 
processing). 


The five external formats are: (1) ex- 
ternal or zoned decimal, (2) external 
floating point, (3) sterling display, (4) 
report, and (5) sterling report. The three 
internal formats are: (1) internal or 
packed decimal, (2) binary, and (3) intern- 
al floating point. 


The conversions from internal decimal to 
external decimal, from external decimal to 
internal decimal, and from internal decimal 
to report are done in-line. The other con- 
versions are performed by the COBOL library 
subroutines shown in Table 17. 
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COBOL LIBRARY ARITHMETIC SUBROUTINES 


Most arithmetic operations are performed 
in-line. However, involved calculations, 
such as exponentiation, and calculations 
with very large numbers, such as decimal 
multiplication of two 30-digit numbers, are 
performed by COBOL library subroutines. 
These subroutine names and their functions 
are shown in Table 18. 


COBOL LIBRARY INPUT/OUTPUT SUBROUTINES 


The input/output subroutines are for the 
verbs DISPLAY (TRACE and EXHIBIT), ACCEPT, 
and BSAM WRITE and CLOSE. 


(ZHDFDISP) 


The IHDFDISP subroutine is used to 
print, punch, or type data, usually in 
limited amounts, on an output unit. TRACE 
and EXHIBIT are kinds of DISPLAY. 


The acceptable forms of data for this 
subroutine are: 


1. Display 
2e External decimal 


3. Internal decimal (converted by the 
subroutine to external decimal) 


4. Binary (converted by the subroutine to 
external decimal) 


5. External floating point 


Internal floating-point numbers must be 
converted to external floating point before 
the subroutine is called. 


ACCEPT Subroutine (IHDFACPT) 


The IHDFACPT subroutine is called to 
read from SYSIN or from the operator's con- 
sole at execution time. For SYSIN, a maxi- 
mum of 80 characters is accepted and moved 
to the specified operand. For the console, 
a maximum of 255 characters are accepted 
and either 255 characters or the length of 
the operand, whichever is smaller, is moved 
to the operand. 
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Table 17. 


' 
{ 
( 
! 
! 
t 
t 
{ 
! 
( 
t 
( 
{ 
{ 
( 
( 
t 
t 
( 
! 
t 
t 
t 


( 
' 
t 
t 
( 
t 
| 
t 
( 
! 
t 
! 
! 
t 
! 
{ 
1 
! 
! 
t 
! 
! 
{ 


1The entry points used depend on whether the double-precision number is in registers 0 
2 and 3, or 4 and 5, respectively. 
2The entry points are for single-precision binary and double-precision binary, respec- 


and i, 


Subroutine Name 
and Entry Points 


eS a ES SS AT ALE SE AS RT EP EE OY ES eS A OS ee 


THDFEFID 


THDFEFBI 


IHDFEFIF 


IHDFBIID+ 
IHDFBID21 


IHDFBID4&2t 


IHDFBIED+ 
IHDFBIX21 
IHDFBIEX+ 
IHDFBIIF2 
IHDFBIFD2 


IHDFBIIL®? 


| 
' 
! 
{ 
{ 
{ 
I 
1 
{ 
| 
{ 
| 
I 
{ 
| 
I 
| 
{ 
t 
{ 
{ 
( 
{ 


IHDFTEFP?2 
IHDFBIFL? 
THDFIDEF 


IHDFIFEF 


PF A EE A SE OS SE OS A AY A CD A 


IHDFIDBI 


IHDFEDBI 


IHDFIDIF 


IHDFDCIF 


Pe eS AS EF A A EP A A A NT I ES Se SD SD DS Ee 


IHDFIFID 


THDFIFEX 


External Floating Point 
External Floating Point 


External Floating Point 


Binary 


Functions of COBOL Library Conversion Subroutine (Part 1 of 2) 
Bite Sa oe a ea eee a ee a ee 1 


Internal Floating Point 


3This entry point is used for calls from other COBOL library subroutines. 


a i a a a ae oe a ne ee ee ee J 
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] 
ie 
| tively. 


Conversion | 

SRS etSSe ssa a sere Seana qo See eee eee eed 
| | 

| To | 
------------------------------- }-------------+-----------------4 
] Internal Decimal | 

| | 

| | 

| | 

| | 
~---------=---------=---------- }--------------------=----------| 
Binary | Internal Decimal | 

| | 

| | 

| | 

| | 

wocn ren ene eon nen e === }-+-----------------------------4 
Binary | External Decimal | 

| | 

| | 

| | 

| | 

SP ee ee ge eee eae ee 2 anit ALR R TIT pained | 
Binary | Internal Floating Point | 

| | 

| | 

| | 

| | 

Prag ar ee ee a a eee eee a pee 1 Gans aA ARC Se a RIO RUDE Een { 
Binary ] External Floating Point | 

| | 

| | 

; | | 

Internal Decimal ] External Floating Point | 

| | 

Internal Floating Point | External Floating Point | 

i te at Sa ei re a nt 4—.-~—------- +--+ +--+ - | 
Internal Decimal | Binary | 

| 

External Decimal | Binary | 
Detecakciew eae eae mos 4------------------~------------] 
Internal Decimal | Internal Floating Point | 

| | 

External Decimal | Internal Floating Point | 
~------------------------------ }--~---------------------------- 
Internal Floating Point ] Internal Decimal | 

| | 

Internal Floating Point | External Decimal | 

Meee acral le eae ade el ata 4 


Table 17. Functions of COBOL Library Conversion Subroutines (Part 2 of 2) 


See or a ee Mr ae ee en ee eee ee ea ag Oe pee as 1 
| | Conversion | 
| ; pm a aaa { 
| Subroutine Name | | | 
1 and Entry Points | From | To | 
|——--------------------- | ---—-—~ === =~ }---------------------—--------- { 
| IHDFIFBI | Internal Floating Point H Binary integer and a power | 
} | | of 10 exponent | 
| IHDFIFBX3 | | | 
| IHDFIFBD | Internal Floating Point | Binary | 
|------------- ---------- }-------------------------~----- {------------------------------- { 
| IHDFIDSR {| Internal Decimal | Sterling Report | 
{----------------------- }------------ ~------------------ 4------------------------------- { 
{ IHDFIDST | Internal Decimal | Sterling Non-Report | 
}-----------------------4------------------------------- 4------------------------------- { 
| IHDFSTID | Sterling Non-Report | Internal Decimal | 
a lee eee eee ee ae ee ee eee ee a ap sapere ORC a ee te MONE ve Eephe mnTn to ear PR ME Kine PCN SLO OTE NEE eo TON Mn PENT EN PS USE OT 
{*The entry points used depend on whether the double-precision number is in registers 0 | 
| and 1, 2 and 3, or 4 and 5, respectively. | 
|#The entry points are for single-precision binary and double-precision binary, | 
| respectively. | 
|*This entry point is used for calls from other COBOL library subroutines. | 
a a a ea ee J 
Table 18. Functions of COBOL Library Arithmetic Subroutines 

Signe ea ceacebe ein ated ei eenence ebb oSuet eae aah aoe sane oee aaa nae 
| Subroutine Name} Function | 

wa a2----- === 4-------------------------------------------------------------=---------4 
| IHDFXMUL } Internal Decimal Multiplication (30 digits * 30 digits = 60 digits) | 
--------------- |-------------~-------------------------------------=-------------------| 
| TIHDFXDIV | Internal Decimal Division (60 digits/30 digits = 30 digits) | 
-----~--------- 4-----------------------------------------------------------------------4 
{ IHDFXPWR | Exponentiation of an Internal Decimal Base by a Binary exponent | 
ee }—-------—------------~-+---------- —- + + -- - -- - - - - | 
| THDFFPWR { Floating-Point Exponentiation | 
f----—---------- 4-----------------------------+---------------------------------------=- { 
{ LHDFGPWR?+ {| Floating-Point Exponentiation | 
}--------------- 1_--~-----------------~~-----~-~---------------------------------------- 1 


]*The IHDFGPWR entry point is used if the exponent has a picture specifying an integer. | 
| The IHDFFPWR entry point is used in all other cases. | 


Veo ee es ee ee ee SS 


BSAM WRITE and CLOSE Subroutine (IHDFBSAM) 


The IHDFBSAM routine is used only for 
the WRITE and CLOSE (output) statements for 
BSAM files. 


SORT FEATURE SUBROUTINE (IHDFSORT) 


The IHDFSORT routine acts as an inter- 
face between the COBOL calling program and 
the SORT/MERGE program. 


COBOL LIBRARY SUBROUTINES FOR OTHER VERBS 


There are also COBOL library subroutines 
for the comparisons, the verbs MOVE and 
TRANSFORM and the RERUN clause. 


ae ae a ae i ce on ae ee ee ee ee J 


COMPARE Subroutine (IHDFVCOM) 


SS ES ES SS ES 


The IHDFVCOM subroutine compares two 
operands, one or both of which is variable 
in length. They may exceed 256 bytes. 


MOVE Subroutine (IHDFVMOV_and IHDFVMVvg) 


The MOVE subroutine is used when one or 
both operands is variable in length. They 
may exceed 256 bytes. The subroutine has 
two entry-points, depending on the type of 
move: IHDFVMOV (left-justified) and 
IHDFVMVI (right-justified). 
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TRANSFORM Subroutine (IHDFVTRN) 


The IHDFVTRN subroutine translates 
variable-length items. 


The IHDFCLAS subroutine is used to per- 
form class tests for variable-length items 
and those fixed length items over 256 bytes 
long. 


Note: The following tables are placed in 
the library for use by the in-line coding 
generated and the subroutines called for by 
both class test and TRANSFORM: 


IHDFATBL 
ITHDFETBL 


IHDFITBL 
IHDFTRAN 
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RERUN Subroutine (IHDCKPT) 


The IHDCKPT subroutine is used to take 
checkpoints on a file specified on the 
RERUN clause. It saves registers, issues 
the checkpoint macro-instruction (CHKPT), 
restores the calling registers and returns 
control to the program. 


When a file named in a RERUN clause is 
opened, a checkpoint counter for that file 
is set to a value of 1 in order to take a 
checkpoint before the first record is proc- 
essed. Each time a READ or WRITE occurs, 
the compiler generates code to test the 
checkpoint counter. If the counter equals 
1, the IHDCKPT subroutine is called, a 
checkpoint is taken, and the counter is 
reset to the integer value specified in the 
RERUN clause. If the counter is not equal 
to 1, it is decremented by 1 and no check- 
point is taken. 


In this appendix, each field of the data 
control block is listed by the name of the 
operand of the assembler language macro 
instruction that can specify a value for 
that field. Tables 19 through 24 
illustrate the data control blocks for the 
following file processing techniques: 

QSAM, BSAM, QISAM, BISAM, and BDAM. Some 
of the data control block fields, can be 
referred to with the DCB parameter of the 
DD statement. However, any field filled in 
by the COBOL compiler cannot be overridden. 


Values for fields for which no entry 
appears in the column headed "COBOL Source" 


APPENDIX C: 


FIELDS OF THE DATA CONTROL BLOCK 


may be supplied by the DD statement or by 
the data set label. 


For information concerning the specifi- 
cation of values for data control block 
fields, see the DCB macro-instruction for 
the different file processing techniques in 


the publication IBM System/360 Operating 
System: Supervisor and Data Management 


Macro-Instructions, Form C28-6647. 


Note: The DCB subparameters are discussed 
under “User Defined Files" in the chapter 
"Execution Time Data Set Requirements." 
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Table 19. Data Control Block for QSAM 
(r= =SS----= Te ee ee eee oe 


| | 
|Data Control] 


{Block Field ]Explanation of Field 
eesererr ener 4------------------------- 


Data set organization 


| 
| 
| 
| 
l 


1 
| 
| 
| MACRF |Type of macro instruction|OPEN INPUT 
| ] | OPEN OUTPUT 
| | |OPEN I-O 
| | | 
| DDNAME }Name of DD statement |ASSIGN TO external-name 
| | 
| DEVD {|Device(s) on which the | 
| ] data set may reside and| 
| | device-dependent | 
| { information | 
| | | 
| OPTCD jOptional service provided| 
| } by the control program | 
| | | 
] RECFM {Characteristics of the ] RECORDING MODE 
{ } records in the data set|BLOCK CONTAINS 
| | | WRITE... AFTER. ADVANCING 
| ] l 
| LRECL ] Logical record length ]RECORD CONTAINS 
] l | 
| BLKSIZE ]Maximum length of block |BLOCK CONTAINS integer 
i ] ] RECORDS 
| | | 
] BFTEK |Type of buffering (S,E) | (COBOL specifies S) 
| | | 
| BUFNO |Number of buffers | SAME AREA 
| ] assigned to DCB | RESERVE 
| | 
| BFALN ]Buffer boundary alignment]| (COBOL compiler specifies 
| 1 | double-word boundary) 
| | | 
| BUFCB j|Address of buffer pool |SAME AREA 
| | | 
| EODAD+ |Address of user's end-of-jREAD. . .AT END 
i | data-set exit routine | 
] | for input data set | 
| | | 
| SYNAD | Address of error exit J} USE AFTER ERROR 
| { routine | ON file-name 
| | | 
] EROPT jError option | 
1 


PS ee SS ce A ce A oS SE SS EE GS GS ks ES A A Se 
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| ORGANIZATION omitted 
JACCESS IS SEQUENTIAL 
| or omitted 


a ce ce ce ce a te cee ce ce ee ee ee cee ee a ee oe ee ee 


Applicable 
DD Statement 
DCB Subparameters 


[TRTCH=,DEN=, 
MODE=, STACK=]) 


(OPTCD={W]C|WC]) 


BLKSI ZE=xxx 
(if integer=0 in 
BLOCK CONTAINS) 


BUFNO=xxx 


e Table 20. Data Control Block for BSAM 


ta mm aaa aaa == -S—= ee a a To Ge ee ge 1 
| | { {| Applicable | 
{Data Control| | | DD Statement 
{Block Field |Explanation of Field l COBOL Source {| DCB Subparameters | 
aaa Teas nes mga | 
| DSORG |Data set organization | ORGANIZATION IS | DSORG=DA | 
{ | | DIRECT | (must be included | 
| | | RELATIVE | for output files) | 
| | ACCESS IS SEQUENTIAL | 
| l | | | 
{ MACRF [Type of macro instruction | OPEN INPUT | | 
| | | OPEN OUTPUT | | 
{ | { | | 
| DDNAME |Name of DD statement | ASSIGN TO external-name | | 
| | | | 
| DEVD |Device(s) on which {| ACTUAL KEY | | 
1 | data set may reside | | 
| | | | | 
{ OPTCD {Optional service to be | | (OPTCD= [option] ) ] 
{ | provided by the control | | | 
{| program { | 
| l | | 
{ RECFM | Characteristics of the { RECORDING MODE | | 
| | records in the data set | | | 
| | | | | 
| LRECL {Logical record length | RECORD CONTAINS | | 
| | { | | 
| BLKSIZE |Maximum block length | RECORD CONTAINS | | 
| | { | | 
[NCP {Maximum number of read or | Option 1 of the APPLY | ] 
| | write macro-instructions| clause | | 
{ { issued before a check | | | 
| 1 macro-instruction | | | 
| | | [ | 
| BUFNO {Number of buffers assigned| one | ] 
| | to DCB | | | 
| | | | { 
| EODAD+ jAddress of end-of-data-set| READ...AT END | | 
| | exit (input) | | | 
I . | | | | 
{| SYNAD {Address of error exit | USE AFTER ERROR ON | | 
| | | file-name | | 
{---------~~~~ a a a a te eo he ee eee dee eee eee | 
{+This field is filled in when the file is read. | 
sie a hah Se oR ar a a Nr a a a Ne tae J 
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e Table 21. Data Control Block for QISAM (load mode*) 


madras taal ai er et an ee Rp ee ee ae Oe So ee a a pe 
| | Applicable 

[Data Control] | DD Statement 

{Block Field ]Explanation of Field ] COBOL Source DCB Subparameters 

i a i a i aes ee es ae ee a a a SS ee + (Se ee ee ee eee Se ee eee 

{ DSORG {Data set organization | ORGANI ZATION INDEXED DSORG=IS 


JACCESS IS SEQUENTIAL 
| or omitted 


(required) 


+ 
| 
| 
1 
+ 
| 
{ | 
| | 
| | | | 
|] MACRF ]Type of macro instruction JOPEN OUTPUT | 
| | | | 
| DDNAME |Name of DD statement |ASSIGN TO external-name _ | 
| | | | 
| OPTCD {Optional service provided | JOPTCD= (W|M|Y]I[R] 
| 1 by the control program? | ] (more than one 
| | | | code can be 
| | } specified) 
| | | | 
| RECFM {Characteristics of the | RECORDING MODE | 
| ] records in the data set }BLOCK CONTAINS | 
| | | | 
| LRECL jLogical record length [RECORD CONTAINS | 
| | | 
| BLKSIZE {Maximum length of block ]BLOCK CONTAINS integer | BLKSI ZE=xxx 
| | | RECORDS l (IF integer=0 in 
| | | | BLOCK CONTAINS) 
| | i | 
| RKP {Relative position of record]RECORD KEY clause | 
| {| key in logical record l | 
| | | | 
| NTM |Maximum number of cylinder ] | NIM=xx 
| | index tracks ] | 
{ | | | 
| KEYLEN {Length of key for each |RECORD KEY | 
{ 1 physical record j | 
| | | | 
{ CYLOFL { Number of overflow tracks ] | CYLOFL=xx 
| | for each cylinder | | 
| | | | 
| BUFNO {Number of buffers assigned |RESERVE | BUFNO=xxx 
{ | to DCB 1 | 
| | ; | ; o9 4% al 
| BFALN |Buffer boundary alignment | (COBOL compiler specifies | 
| | } double-word boundary) | 
| | i | 
| BUFCB {Address of buffer pool |SAME AREA | 
| | { | 
{| SYNAD {Address of error exit |USE AFTER ERROR ON | 
{ | routine } file-name | 
| | | or 
| | } INVALID KEY statement | 
eee eee Ee Oo SR eee oe i ae tessa andes ae Ce a ee a 


{+The load mode is used to create an indexed sequential file. 
{2At OPEN time, this field is updated to include the delete code option, in addition 
{ to any options specified in the DD statement. 
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1 


| 
| 
| 
j 


ee en ey 


Table 22. Data Control Block for QISAM (scan mode?) 
(Seas Ss —= an cad a aa iam a i am aan 7S SS eS 1 


[Data Control 


{Block Field |Explanation of Field 


Applicable 
DD Statement 
DCB Subparameters | 


| 

| 

1 
SyeneTuiaieeiatanad. Sota enapenianpebuuar eee peaReEREnEnetmne po=pereetos pune eee eNNaTeNaneReia 4-------------------- { 
| DSORG jData set organization ] ORGANI ZATION INDEXED | DSORG=1IS | 
t | |ACCESS IS SEQUENTIAL | (required) | 
{ J | or omitted | | 
[ I | | [ 
{ MACRF ]Type of macro instruction |OPEN INPUT | | 
| | |OPEN I-o | | 
{ { | | | 
| DDNAME [Name of DD statement {ASSIGN TO external-name _ {| | 
| i | | | 
| RECFM2 | Characteristics of the | RECORDING MODE | | 
{ } records in the data set |BLOCK CONTAINS | ] 
| | | | | 
{ LRECL2 {Logical record length | RECORD CONTAINS | | 
| | | | | 
{ BLKSIZE2 |Maximum length of block ]BLOCK CONTAINS integer | | 
| | | RECORDS | | 
| | | | | 
| BFTEK2 {Type of buffering (S,E) | (COBOL specifies S) | 
| | | | | 
| BUFNO | Number of buffers assigned | RESERVE | BUFNO=xxx | 
{ | to DCB | | | 
| | | | | 
|] BFALN |Buffer boundary alignment |(COBOL compiler specifies | ] 
| | | double-word boundary) | | 
i | | { ] 
| BUFCB {Address of buffer pool {SAME AREA | | 
{ | { | ] 
| EODAD jAddress of user's end-of- {|READ...AT END | | 
{ {| file exit routine for { { | 
( i files opened as input | I | 
{ | | | l 
| SYNAD | Address of error exit {USE AFTER ERROR ON | | 
| {| routine { file-name | 
}——-—-—-_-—- Be seen eh SRE SE ace IP TE Ie ene eR a ERP Er eae ES SyeREn ee os cate ae ee ~----4 
{The scan mode is used to retrieve and update records in an indexed sequential file. j 
]#The information for these fields is obtained from the data set label. It is stored | 
{ there when the data set is created. However, the COBOL user must still specify the | 
{ COBOL clauses in his source program. | 
rae a oe eR ee TERA a a I Re Ee IONE TE a RE ES ONES Te IEEE EE oD Se SEIT J 
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Table 23. Data Control Block for BISAM 


t 
| 
! 
! 
! 
! 
1 
! 
! 
t 
{ 
t 
] 
! 
! 
! 
{ 
! 
! 
! 
- 


T T 
| | Applicable | 
|Data Control] | ] DD Statement | 
{Block Field |Explanation of Field | COBOL Source | DCB Subparameters | 
|------------}--------------------------- +------------------------- 4-------------------- { 
{ DSORG |] Data set organization |] ORGANIZATION IS INDEXED | DSORG=IS | 
| | {ACCESS IS RANDOM f | 
| | | | 
| MACRF {Type of macro instruction |OPEN I-O, READ, WRITE | | 
| J | OPEN I-O, READ, REWRITE, | | 
| | | WRITE | | 
{ | | OPEN INPUT, READ | | 
| | | | | 
| DDNAME |Name of DD statement JASSIGN TO external name _ | ] 
| i t | 
| NCP {Number of channel programs |Option 1 of the APPLY | | 
| { to be established for } clause | | 
{ | this DCB | | | 
| | | 
{MSWA |Address of main storage |] TRACK-AREA IS data-name_ | ] 
{ ] work area reserved for | TRACK-AREA IS integer | | 
| ] the control program. Re- | CHARACTERS | | 
| } quired when new variable-| | | 
} ] length records are | | | 
i | being added. | | | 
| l | | | 
| SMSW {Number of bytes reserved |] TRACK-AREA IS data-name _ | | 
| ] for main storage work ] TRACK-AREA IS integer | | 
d ] areae | CHARACTERS | | 
bee Se est ete ares eerie ele ee ee a a a tar ar aie cea ec es Ms Ns a re J 
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Table 24. Data Control Block for BDAM 


(= Aa eS Se SSS SS SoS gg ema 1 
| | | |Applicable | 
{Data Control | | {DD Statement | 
|Block Field |Explanation of Field | COBOL Source {DCB Subparameters | 
oe tee ee | Sad eee oe 
| DSORG |Data set organization | ORGANIZATION IS I 
| | | DIRECT | | 
| | | RELATIVE | { 
{ | | ACCESS IS RANDOM | | 
| | | | 
| MACRF {Type of macro instruction |OPEN INPUT, READ | | 
| | JOPEN I-0O, READ, REWRITE | | 
| | | OPEN INPUT, READ, ACTUAL | | 
| | | KEY | | 
H | JOPEN I-O, READ, REWRITE, ] ] 
| | | OPEN I-O, READ, REWRITE, ] | 
| | | WRITE J | 
| | | | 
| DDNAME |Name of DD statement |ASSIGN TO external-name | | 
| | | | | 
{ OPTCD | Optional service to be | APPLY RESTRICTED SEARCH | | 
| { provided by the control {| | | 
ene | | | 
| RECFM |Characteristics of the |RECORDING MODE IS U | | 
1 | records in the data set |RECORDING MODE IS V | | 
| | | RECORDING MODE IS F | | 
| | | { | 
| KEYLEN [Length of key for each | SYMBOLIC KEY | | 
| | physical record | | | 
| | | | | 
| LIMCT {Maximum number of tracks |APPLY RESTRICTED SEARCH ON| | 
Hi | or blocks to be searched | integer TRACKS | | 
j | (extended search) Jno APPLY RESTRICTED SEARCH | | 
beste et a ah a ee es Pom oe oe eee ee ee Nis ee a Se 5 
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In general, compilation is faster if: 
1. Options in the EXEC statement are 
specified 


a. making more main storage available 
(the SIZE option), 


b. optimizing the space available for 
buffers (the BUF option), 


Cc. suppressing output (the NOSOURCE, 
NODECK, NOLOAD, and the NOMAP 
options). 


dad. suppressing object code listing 
and object and linkage edit decks 
(the SUPMAP option only if E level 
messages are present). 


e. specifying the option CLIST, which 
will result in a condensed 
listing. 


2. The maximum block size for a compiler 
data set is specified. 


3. <A disk configuration and separate 
channels for utility data sets are 
used. 


4. Separate devices (i.e., not the same 
direct-access unit) on the same chan- 
nel are used. 


Compilation time is also affected by the 
speed of the devices allocated to the data 
sets. For example, a tape device is faster 
than a printer for printed output. The 
blocking information that follows applies 
to PCP, MFT, and MVT. 


BLOCK SIZE FOR COMPILER DATA SETS 


The blocking factor specified for com- 
piler data sets other than utility data 
sets must be permissible for the device the 
data set is on. In addition, for the SYS- 
LIN data set, it must be permissible for 
the linkage editor used. (Any block size 
specified for a utility data set in a DD 
statement is overridden by the compiler.) 
If a block size other than the default 
option is needed, it can be requested by 
specifying the BLKSIZE subparameter of the 
DCB parameter in the DD statement for the 
data sets. The format of the subparameter 
is: 
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DCB=(, BLKSIZE=nnn) 


where nnn is equal to N times the logical 
record size in bytes, and 1<N<M. Mis 
equal to the blocking factor permissible 
for the device, and, in the case of SYSLIN, 
to the blocking factor permissible for the 
linkage editor used. 


If blocking is desired, the record for- 
mat for SYSPRINT (DCB=(,RECFM=nnn)] should 
be specified as FBA. The record format for 
SYSIN, SYSLIN, SYSPUNCH, and SYSLIB should 
be specified as FB. 


The logical record size for SYSPRINT is 
121 bytes. The logical record size for 
SYSIN, SYSLIN, SYSPUNCH, and SYSLIB is 80 
bytes. 


Note: For compile, linkage edit, and 
execute cases when labeled volumes are 
used, RECFM and BLKSIZE must be given for 
SYSLIN in the compile step only. If 
BLKSIZE is specified for SYSPUNCH, LRECL 
must also be specified. The 44K version of 
the linkage editor supports input data sets 
with a blocking factor of up to 40 
specified. 


HOW BUFFER SPACE IS ALLOCATED TO BUFFERS 


Once the amount of Space available for a 
compilation is determined, the compiler 
subtracts the amount required for itself. 
From the space remaining, it then computes 
the space available for utility and input/ 
output data set buffers. If space still 
remains, it is used for the compiler's 
internal processing. 


Once the compiler determines the amount 
of space available for buffers, it calcu- 
lates how this space is to be divided. 
First, it computes the amount of space re- 
quired for the buffers of the input/output 
data sets. From the space remaining, it 
determines the maximum buffer size, and 
hence block size, possible for a utility 
data set. The utility data sets all have 
the same block size. Hence, the block size 
of a utility data set is dependent on the 
amount of space available for buffers. If 
a block size has been specified on a DD 
statement for a utility data set, it is 
overridden. 


A larger buffer size for a utility data 
set allows for faster processing. However, 
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if the program that is being compiled takes 
up a large amount of the available storage, 
a smaller space for buffers enables the 
compiler to use more main storage for 
internal processing. 


The following describes how the space 
available for buffers is determined and how 
it is allocated for buffers. 


Let A represent the space that can be 
allocated to these buffers. It is deter- 
mined as follows: 


1. If neither the BUF nor the SIZE option 
of the PARM parameter of the EXEC 
statement is specified, A equals the 
default value for buffer space. This 
value is specified at system genera- 
tion time. The minimum value is 2762 
bytes. 


2. If the SIZE option is specified, 
but BUF is not, A equals (SIZE-80K)/4 
plus the default value for buffer 
space. 


3. If BUF is specified (whether or 
not SIZE is specified), A equals the 
value specified for BUF. 


4. If BUF is smaller than 2762 bytes (the 
minimum value), a warning message is 
printed and the minimum valve is 
assumed. 
minimum table space for compilation, a 
warning message is printed and the 
default value (or the minimum value, 
if the default value is also too 
large) is assumed. 


The programmer must make sure that the 
amount of buffer space allocated by the 
system is sufficient, taking into consid- 
eration the block sizes specified for the 
compiler data sets. The allocated buffer 
space is divided as follows: 
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If BUF is too large to allow. 


1. Let B represent the amount of buffer 
space to be allocated for input/output 
data sets. B is computed as either 
equal to: 


2 times the block size of SYSPRINT + 
SYSIN + SYSLIB 


or 


2 times the block size of SYSPRINT + 
SYSPUNCH + SYSLIN 


whichever is larger. The maximum allowable 
value of B is A-1280 bytes. If the com- 
puted value is greater than the maximum 
allowable value, a diagnostic message is 
printed and compilation is abandoned. 


If the block sizes are not specified in 
the DD statements, the following default 
values are assumed: 

SYSIN, SYSLIN, SYSLIB: 80 
bytes each 


SYSPUNCH, 


SYSPRINT: 121 bytes 

2. Let C represent the amount of buffer 
space to be allocated for each utility 
data set. Therefore, C equals the 
block size of data sets, SYSUT1, SYS- 
UT2, SYSUT3 and SYSUT4, respectively. 


then C = A-B 


5 


If A < 6B, 


I 


If A> 6B, thenC =A 
6 


If C > maximum block size permitted for 
any device a utility data set is on, then 
the maximum block size is the value chosen 
for Ce. The minimum block size for a utili- 
ty data set is 255 bytes. 
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The COBOL (F) compiler can be invoked by 
a problem program at execution time through 
the use of the ATTACH or LINK macro 
instruction, i.e., dynamic invocation. 
Dynamic invocation of COBOL (F) compiled 
programs can be accomplished through the 
use of the LINK or LOAD macro instruction. 


INVOKING THE COBOL (F) COMPILER 


The problem program must supply the fol- 
lowing information to the COBOL (F) 
compiler: 


e The options to be specified for the 
compilation 


e The ddnames of the data sets to be used 
during processing by the COBOL (F) 
compiler 


e The header to appear on each page of 
the listing 


fos Se LS ee ee a 1 
| Operation] operand | 


k 
| (symbo1] | LINK 
| | ATTACH 


| EP=IEQCBLOO | 
| PARAM=(optionlist | 

{,ddnamelist], | 
{,headerlist]),VL=1 | 


specifies the symbolic name of the 
COBOL (F) compiler. The entry point 
at which execution is to begin is 
determined by the control program 
(from the library directory entry). 


PARAM 
specifies, as a sublist, address 
parameters to be passed from the 
problem program to the COBOL (F) com- 
piler. “The first fullword in the 
address parameter list contains the 
address of the COBOL option list. The 
second fullword contains the address 
of ddname list. If standard ddnames 
are to be used and no header list spe- 
cified, this list may be omitted. If 
Standard ddnames are to be used and a 
header list is specified, this entry 
should contain the address of a word 
of binary zeros, aligned on a half- 
word. The last fullword contains the 
address of the header list. This list 
may be omitted. 
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Invocation of the COBOL (F) Compiler and COBOL (F) 


INVOCATION OF THE COBOL (F) COMPILER AND COBOL (F) COMPILED PROGRAMS 


option list 
specifies the address of a variable 
length list containing the COBOL 
options which are specified for compi- 
lation. See the description of the 
EXEC statement "Job Control Pro- 
cedures" for more details. This 
address must be written even though no 
list is provided. 


The option list must begin on a half- 
word boundary. The two high-order 
bytes contain a count of the number of 
bytes in the remainder of the list. 

If no options are specified, the count 
must be zero. The option list is free 
form with each field separated by a 
comma. No blanks or zeros should 
appear in the list. 


ddname list 
specifies the address of a variable 
length list containing alternative 
ddnames for the data sets used during 
COBOL (F) compiler processing. If 
standard ddnames are used, this 
operand may be omitted. 


The ddname list must begin on a half- 
word boundary. The two high-order 
bytes contain a count of the number of 
bytes in the remainder of the list. 
Each name of less than eight bytes 
must be left justified and padded with 
blanks. If an alternate ddname is 
omitted from the list, the standard 
name will be assumed. If the name is 
omitted within the list, the 8-byte 
entry must contain binary zeros. 

Names can be omitted from the end by 
merely shortening the list. 


The sequence of the 8-byte entries in 
the ddname list is as follows: 


Alternate Name For: 
SYSLIN 

not applicable 
not applicable 
SYSLIB 

SYSIN 

SYSPRINT 
SYSPUNCH 
SYSUT1 

SYSUT2 

SYSUT3 

SYSUT4 


tA 
=] 
ct 
K 


POO ONNMNEWNFH 


BE 
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header list 


VL=1 


specifies the address of a variable 
length list containing information to 
be included in the heading on each 
page of the listing. The list must 
begin on a halfword boundary. The two 
high-order bytes should contain a 
count of the number of bytes in the 
new heading information; the next four 
bytes of the list should contain the 
page number at which the heading is to 
start, in EBCDIC format. 


specifies that the sign bit is to be 
set to 1 in the last fullword of the 
address parameter list. 


When the COBOL compiler completes proc- 
essing, a return code is returned in 


register 15. 


See the discussion of the 


COND parameter in "Job Control Procedures" 
for further details. 
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INVOKING COBOL (F) COMPILED PROGRAMS 


Linkage Editor control cards should be 


specified as follows: 


1. 


2. 


For the PROGRAM-ID external name, a 
NAME card. 


For each ENTRY external name, an ALIAS 
card. (All aliases must be specified 
on one card, however.) Since no more 
than five aliases may be specified for 
one load module, only six entries (or 
five entries and the PROGRAM-ID) 
should be specified in a COBOL program 
which is to be dynamically invoked. 


APPENDIX F: SOURCE PROGRAM SIZE CONSIDERATIONS 


Limitations on the size of a COBOL 
source program should be considered in 
relation to the capacities of both the 
COBOL (F) compiler and the various linkage 
editors. This appendix contains informa- 
tion to aid the programmer in determining 
how his source program affects space usage 
at compilation time and linkage editing 
time. 


COMPILER CAPACITY 


The capacity of the COBOL (F) compiler 
is limited by two general conditions: the 
total contiguous space available must be 
sufficient for compilation, and an individ- 
ual table may not have a length greater 
than 32,767 bytes. If either of these con- 
ditions are not met during compilation, one 
of the following error messages will be 
issued: 


TEQOOOII ~- SIZE PARAMETER TOO SMALL FOR 
THIS PROGRAM. 


IEQ00101 - A TABLE HAS EXCEEDED THE MAXIMUM 
PERMISSIBLE SIZE. 


In either case, compilation is terminated. 
However, in the first case, the program may 
be recompiled with a larger size parameter. 


The following information can be used in 
planning or adjusting a COBOL source pro- 
gram in order to permit compilation: 


1. Procedure-name definitions and refer- 
ences: In any one section of the Pro- 
cedure Division, the number of unre- 
solved procedure-name definitions and 
procedure-name references may not 
exceed 900. A procedure-name that is 
defined in a section of the program is 
unresolved until the section is 
reached. A procedure-name reference 
is unresolved until the procedure-name 
itself is defined and resolved. Keep- 
ing forward referencing to a minimum, 
then, would increase the amount of 
space available. 

2. Qualification of names: Name qualifi- 
cation requires a considerable amount 
of space, including increased table 
lengths, and should be avoided when 
possible. Some of the areas where 
qualification uses table space are: 


ae RECORD KEY, SYMBOLIC KEY, and 
ACTUAL KEY clauses. 


4. 
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b. Procedure-name processing. No 
more than 900 procedure-names may 
be qualified in a program. 


ce. Report Writer. Information con- 
cerning each Report Description 
entry (generated labels of appli- 
cable routines, controls, sums, 
headings, footings, etc.) is 
maintained in tables during 
compilation. 


Some of this information is re- 
leased from the tables at the end 
of the report group, some at the 
end of the Report Description 
entry, and some at the end of the 
Report Section. Name qualifica- 
tion and subscripting make the | 
information tables still larger. 
No more than 30 reports can be. 
processed by the compiler without 
approaching the limits on the size 
of these tables. 


Error table: In order to avoid re- 
winding or rereading a file, a table 
is maintained during processing con- 
taining notation about errors encoun- 
tered during compilation. No more 
than 3,000 entries can be made in this 
table. 


Addr constant tabl. In order to 
reduce the amount of space used by 
text records that are out of sequence, 
the COBOL (F) compiler stores items 
that will be used as address constants 
in an address constant table. The 
maximum number of entries in this 
table is 4644. The number of entries 
made in this table will be governed 
mostly by the number of each of the 
following items in the program: 


a. Files (BSAM, BDAM, ISAM) 


b. Files for which a SAME AREA clause 
is specified 


c. Referenced procedure-names 


d. Generated procedure-names (from 
IF, ONSIZE ERROR, AT END) 


e. Varied-names. Two for each ALTER 
Or PERFORM procedure-name or for 
the first procedure-name of PER- 
FORM THRU. 


f. USE sentence 
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5. Miscellaneous: The appearance of the 36 
following items in a program causes 
entries to be made into tables, which 
can greatly reduce the amount of total 


space available for compilation: 


a. Procedure-names (no more than 16, 
380 may be specified); note, 
however, further restrictions on 
number of procedure-names that can 
be referred to. 


b. Literals (no more than 16,380 may 
be specified; total length of 
literals may not exceed 32,760 4. 
bytes) 


Ce OCCURS...DEPENDING ON clauses 
d. Subscripting 

e. Intermediate arithmetic results 
£. Complex arithmetic expressions 


ge Complex logical expressions 


LINKAGE EDITOR CAPACITY 


Some COBOL program and linkage editor 
considerations are listed below as a furth- 
er guide in preparing a source program. 
Consult the publication IBM System/360 
Operating System: Linkage Editor, Form 
C28-6538, for additional information on 
linkage editor capacities and processing. 


1. A COBOL (F) object program consists of 
a single CSECT (control section). The 
size of the object module may be 
determined by looking at the location 
of the last instruction in INIT3 in 
the object code listing (see the sec- 
tion entitled "“Output") or from the 
END card. 


2. The size of the object module is 
greatly increased by any of the 


following: 
5 
ae The blocking factor and alternate 
area reservation of basic files 
66 


b. The specification of the SAME AREA 
clause for queued files 
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RLD (Relocation List Dictionary) cards 
are part of the load module, and are 
used by the linkage editor to compute 
the address constants for the load 
module. The number of RLDs produced 
by the compiler can be determined by 
the following formula: 


No. of RLDs = (no. of unique subpro- 
grams called) + (no. of COBOL (F) 
library routines called) + (no. of 
ENTRY statements) + 7. 


The output text of the compiler is 
written out in a sequence that differs 
from the order indicated by the loca- 
tion counters contained in each output 
item. This sequence difference may 
result in a strain on the facilities 
of the linkage editor. The output 
items are written out in the following 
order: 


ae Constant global table items, in- 
cluding TALLY, random processing 
information, virtuals, literals 

b. Procedure Division 

ce INIT1 

d. DCBs and DECBs 


e. Working-Storage value clauses 


£. Address constants in DCBs, DECBs, 
buffer control blocks, etc. 


ge Global table adcons 


The location counter for each item in- 
dicates the following order: 


ae 4-c 


be. 4-d and 4-f intermixed, with 
overlays 


Ce 4-e 


de. 4-a and 4-g intermixed, with no 
overlays 


Ce 4-b 


Value clauses in the Working-Storage 
Section may result in many discon- 
tinuous text records. 


The object module produced by the 
COBOL (F) compiler may not be sorted 
prior to the linkage editor step. 


es ee ee ae DO SS Se SE SS a SN 


This appendix contains a brief summary of I/O error conditions for 
each of the file processing techniques. More detailed information on 
error conditions can be found by consulting the publications, IBM 
System/360 Operating System: Supervisor and Data Management Macro- 
Instructions, Form C28-6647, and IBM System/360 Operating System: __Sys— 
tem Control Blocks, Form C28-6628. 


QSAM/BSAM_ File Processing Techniques 


Register 1 contains error bits detailing the exact cause of an error. 
Conditions causing input/output errors and suggested user responses are 
as follows: 


Input Error 
Processing of the file is limited to| 
CLOSE. For QSAM, display the error | 
message and then execute the EROPT 
Invalid Request (BSAM only) option in the DD statement. (The 
EROPT option gives the user three 
choices: 


N Re 
e 


- Output Error 


W 
e 


tinue processing 


{ 
| 
| 
| 
ACC-accept the error block and con- | 
| 
SKP-skip to the next block. | 

| 

| 


ABE~terminate the job.) 


fo me ee a 
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BDAM File Processing Technique 


The DECB contains two error condition bytes at location DECB + 4, 
Conditions causing input/output errors and suggested user responses are 
as follows: 


daa aa a Noa SS Oe ee ne 1 
j I/O Error Condition | Suggested User Response | 
}--~-~~--------------------~---- {~------------------------------------- { 
ji. Record Not Found {Condition caused by an invalid key. | 
| | Processing of the file may be | 
{2. Invalid Request | continued. | 
l | | 
| ae Requested block outside| | 
| data set. | | 

| | 
b. Attempted to adda | | 
| fixed-length record | | 
| with key beginning with| J 
| HEX FF, | | 
|------------------------------- 4-------------------------------------- 4 
{1.  Uncorrectable I/O Error. {Processing of the file is limited to | 
| | CLOSE. | 
{2. Uncorrectable Error, Not | | 
| I/O | | 
|~----~------------------------- 4-------------------------------------- { 
|1. Space Not Found {Processing of the file may be con- | 
| | tinued. If option 1 of the APPLY | 
| | clause is specified for the file, | 
| | the record may be written by chang- | 
| { ing the actual key. CLOSE, READ or | 
| { REWRITE may be executed for the | 
{ | file. l 
bien a Be es ee ee ee eg each eat ae ie a J 


QISAM File Processing Technique 


The DCB contains two error condition bytes named EXCD1 and EXCD2, at 
location DCB + 80. Conditions causing Input/Output errors and suggested 
user responses are as follows: 


SS ST ST SS ST wer ewe ere er eee eee 1 
Suggested User Response | 


Condition caused by an invalid key. | 
Processing of the file may be | 
continued. | 

Processing of the file is. limited to 
CLOSE. 


' 
| 
! 
! 
| 
| 
1 
! 
{ 
{ 
l 
{ 
{ 
! 
{ 
t 
' 
{ 
! 
t 
1 
! 
! 
! 
t 
I 
| 
t 
{ 
( 
t 


| I/O Error Condition 
Ji. Sequence Check. 


{2. Duplicate Record. 


The user may attempt to bypass the 
block containing the error. If, in 
reading the next block, the error 
does not recur, he may continue pro- 
cessing without closing the file. 

If the error persists, processing of 
the file is limited to CLOSE. 


Ce ae er tes mes meee ene 


eS ce AO SS A A SR eS A ee eS ge a ee ee ee 


re ge ne ee a ee ne ee ee ee aes re ee ee ee eh ee ree oe 


The DECB contains an error condition byte at location DECB + 24, 
Conditions causing input/output errors and suggested user responses are 
as follows: 


(Se re i aa aca a oa lame 1 
| I/O Error Condition | Suggested User Response | 
~-------—-~------------------- }----------+--------------------------+ 
t1.- Record Not Found. {Condition caused by an invalid key. | 
| { Processing of the file may be | 
|2. Duplicate Record. } continued. | 
as aac a a qe ee ee a ee eae { 
{1. Invalid Request. |] Processing of the file is limited to | 
J | CLOSE. | 
Saag SAA SRE Teen ani eee : (aa IST GA ARIE RS Es SG { 
j1. Uncorrectable I/O Error. |The user can try to execute the | 
| { ainstruction again. If the error | 
|2. Unreachable Block--Index ] persists, he should close the file. | 
| cannot be read. | 

| | 
{3. Record Length Check. ] | 
}--~-~-------------------------- }-------------------------------------- 4 
]1. Space Not Found. | Processing of the file may be con- | 
| ] tinued. The record may be written | 
| J after changing the keys and execut- | 
I } ing a write if a cylinder overflow | 
| | area is available for the new value | 
] | of the keys. CLOSE or READ may be _ | 
| | executed for the file. { 
Roi ee ae es Mes Eee Se oor ee ee A J 


Figure 49 contains an error processing summary for the Indexed 
Sequential file processing techniques. 
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[7 a aaa ee ee ee ee ee ee a ee ET ee ee 
|File | | Error Processing Routine Specified | 
{Processing | Type of }------------------------ yoo = yoo ----------- 
]}Technique | Error ]USE AFTER STANDARD ERROR INVALID KEY | None 
See eS 4 -_-_-_-__--} -_~_ > | Sf -- 
{QISAM jUncorrectable]|User must terminate |COBOL executes a STOP]|Abnormal 
] WRITE ] I/O Error ] processing on the file| RUN with a return | Termination 
| (load mode) }—------------- 4 and reload it. { code of 16. User | 
1 |Space Not ] {| must reload the } 
| | Found | | file. | 
[0 feeewnnnnn==--}------------------------ +~-------------------- i 
| | Duplicate ]User must drop the {User must drop the | 
| | Record ] invalid record if he | invalid record if | 
| -------------- 4 wishes to continue. | he wishes to conti-| 
! | Sequence J | nue. | 
| Check | | 
po--~-~----- --------——--- }-----------—------------ o-----------=-------- fo---=--------- 
| QISAM {Uncorrectable]User must terminate |Not applicable. | Abnormal 
] READ | 1/0 Error ] processing on the file| } Termination 
| REWRITE | ] and reload it. The | | 
| (scan mode) | | user may attempt to | | 
| | ] bypass the block in | | 
] | } error and continue | | 
| | ] processing. However, | | 
| | | if the error persists | | 
| | ] he should reload his | | 
{ | ] program. | | 
| }------------- }------------------------ { ! 
1 |Unreachable |Processing may continue | | 
] | Block ] but user must not | | 
| | } process the file in i | 
] | ] error. | | 
[----------- 4-------------}------------------------ }--------------------- $-------------- 
BISAM JUncorrectable|Processing may continue |COBOL executes a STOP|Errors are 
| I/0 Error | but user must not | RUN with a return | ignored and 
-------------- 4 process the record in | code of 16. User | processing 
}Unreachable } error. | must reload the | continues 
| Block | | file. | with unpre- 
~------------ | {| dictable re- 
|Record Length] | } sults. 
| Check | | 
pom n nanan been nnn { | 
|Space Not ]Processing may continue. | | 
Found ] | | 
iS soe }-------+--------—~---~+--- |} ------- -------------- 


L 
| 


| 
| 
| 
| 
| 
1 
| 
| 
| 
| | 
| 
| 
| | 
| 
| 
] 
| 
| 
| 


e Figure 49. E 
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Record Not ] User may change the key |User may change the 


Found ] and attempt the same 
------------- 4 operation. However, 
Duplicate if the error persists 

Record he should drop the 


Ce 
] invalid record in 
} order to continue. 


rror Processing Summary for ISAM Files 


| 
key and attempt the] 
same operation. | 
However, if the | 
error persists he | 
should drop the | 
invalid record in | 
order to continue. | 


This section describes diagnostic mes- 
Sages generated by the system. Compiler 
messagés and object time messages are 
discussed. 


COMPILER DIAGNOSTIC MESSAGES 


Using one of the messages as an example, 
COBOL (F) compiler messages are of the fol- 
lowing format: 


005 IEQ4O46I-E ILLEGAL TO REWRITE*****,A 
BSAM FILE. STATEMENT 
DELETED. 


The code 005 is the card number of the 
statement where the error has occurred. 

IEQ identifies this as a COBOL (F) compiler 
message. 4046 is the identifying number of 
the message. The symbol I means that this 
is a message to the programmer for his 
action. E is a level of severity in the 
error code that is, as follows: 


W Warning -- This level indicates 
that an error was made in the 
source program. However, it is 
not serious enough to hinder the 
execution of the program. 


Cc Conditional -- This level in- 
dicates that an error was made but 
the compiler usually makes a 
corrective assumption. The state- 
ment containing the error is 
retained. Execution can be 
attempted for the debugging value. 


E Error -- This level indicates that 
a serious error was made. Usually 
the compiler makes no corrective 
assumption. The statement con- 
taining the error is dropped. 
Execution of program should not be 
attempted. 


D Disaster -- This level indicates 
that a serious error was made. 
Compilation is not completed. 
Results are unpredictable. 


The severity level of the messages is 
correlated with the return code issued by 
the compiler at the end of compilation (see 
below). This code can be tested by the 
programmer with the COND parameter in the 
EXEC statement. 


APPENDIX H: DIAGNOSTIC MESSAGES 


ee a RS i ee 


Severity Level Return Code 
(No messages) 0 

W 4 

Cc 8 

E 12 

D 16 


The return code indicated is the most 
severe level occurring in the messages. 


The message text is composed of two sen- 
tences. The first sentence describes the 
error; the second describes what the com- 
piler has done as a result of the error. 
Most of the messages are thus self- 
explanatory, except in two situations: 


1. When no compiler action is given. 
These messages are numbered in the 
3000 series. They appear in combina- 
tion with other messages that do have 
the compiler action described. 


2. When messages describe errors that 
require an explanation too long to 
include in a message. These explana- 
tions appear in text under the 
messages. 


Words in a message that must vary according 
to the program being compiled are denoted 
by ***** in the messages printed below. 

The symbol *** appearing in a message on a 
listing means that the compiler has encoun- 
tered unrecognizable information. 


IEQO0001I- SIZE PARAMETER TOO SMALL FOR THIS 
PROGRAM 


Explanation: Compiler was unable 
to allocate sufficient table 
space for the source program. 
User Response: Specify a larger 
amount of main storage in the 
SIZE option of the PARM parameter 
in the EXEC statement, or divide 
the program into smaller segments 
and utilize the overlay feature 
of the linkage editor. 


TEQO002T- INVALID COPY/BASIS LIBRARY NAME 


Explanation: Library name given 
in BASIS, COPY, or INCLUDE state- 
ment does not exist. 


User Response: Check that a SYS- 
LIB DD statement is present that 
defines a library which contains 
the member whose name is speci- 


Appendix H: Diagnostic Messages 199 


TEQO003I- 


ITEQOOO4I- 


ITEQOOO5I- 


ITEQO006I- 


IEQ0007I- 


IEQO008I- 


IEQOOO09T- 
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fied on the BASIS, 
INCLUDE statement. 


COPY, or 


PERMANENT I/O ERROR ON **¥*#*, 
COMPILATION ABANDONED. 


Explanation: ***** is the name 
of the DD statement associated 
with the data set on which the 
input/output error occurred. 


Note: The above message appears 
on the console listing only. 


ILLEGAL PARM OPTION ON EXEC 
STATEMENT. 

*4**%* TNVALID BLOCKSIZE. DEFAULT 

USED. 


Explanation: Blocksize specified 
on DD card is not an integral 
multiple of record length, or 
blocking factor is too large. 


User Response: Change blocksize 
parameter on DD card or accept 
default option. 


*444% DATASET NOT USABLE. 
STEP CANNOT EXECUTE. 


JOB 


anation: Data set required 
by the compiler cannot be opened. 
Program cannot be compiled. 


User Response: Check DD card. 


SYSLIN NOT USABLE. 
CANCELLED. 


LOAD OPTION 


SYSLIN cannot be 


opened. 


User Response: Check DD card. 


SYSPUNCH NOT USABLE. DECK OPTION 
CANCELLED. 

Explanation: SYSPUNCH cannot be 

opened. 


User Response: Check DD card. 


SIZE 

BUF PARAMETER IGNORED. DEFAULT 
USED. 

Explanation: Value of parameters 


is inadequate to calculate table 
and dictionary space for compila- 
tion purposes, or BUF parameter 
is less than minimum required. 


User Response: If the default 
value is unsuitable, increase the 
value for the SIZE parameter or 
decrease the BUF parameter. 


IEQ0010I- 


IEQO015I- 


ITEQO0020I- 


IEQ6001I- 


IEQ6002I- 


IEQ6003I- 


ITEQ6004I- 


IEQ6005I- 


IEQ6006I- 


Note: 


A TABLE HAS EXCEEDED THE MAXIMUM 
PERMISSIBLE SIZE. 


BUF SUBPARAMETER IN PARM FIELD 
TOO SMALL FOR DD CARD BLKSIZE 
SUBPARAMETERS. COMPILATION 
ABANDONED. 


Explanation: The size of the 
buffer used for SYSPUNCH, SYSLIN, 
SYSIN, SYSPRINT, and SYSLIB 
exceeds BUF-1280 bytes. 


User Response: Increase the BUF 
parameter in the EXEC card or 
decrease the BLKSIZE values 
specified in the DD cards for 
SYSPRINT, SYSIN, SYSLIB, SYS- 
PUNCH, or SYSIN. 


LOGIC ERROR OR MACHINE ERROR IN 
TABLE HANDLER. COMPILATION 
ABANDONED. 


ERROR FOUND PROCESSING F4 TEXT. 
00 CODE IN LISTING TEXT. 


ERROR FOUND PROCESSING F4 TEXT. 
END OF LISTING TEXT REACHED. 


ERROR FOUND PROCESSING F4 TEXT. 
UNKNOWN DATA A-TEXT CODE. 


ERROR FOUND PROCESSING F4 TEXT. 
EOF REACHED WHILE PROCESSING 
LISTING TEXT. 


ERROR FOUND PROCESSING F3 TEXT. 
COMPILATION ABANDONED. 


MAP SUPPRESS SPECIFIED AND E 
LEVEL DIAGNOSTIC HAS OCCURRED. 
ONLY DIAGNOSTICS WILL BE 
PRODUCED. 


The preceding messages may be inter- 


spersed in the compiler output listing. 
The following messages are grouped in the 
compiler output listing. 


IEQ1001I- 


ITEQ1002I- 


IEQ1003I- 


IEQ1004I- 


NUMERIC LITERAL NOT RECOGNIZED AS 
LEVEL NUMBER BECAUSE ***** 
ILLEGAL AS USED. SKIPPING TO 
NEXT LEVEL, SECTION OR 
DIVISION. 


****4* SECTION HEADER MISSING. 
ASSUMED PRESENT. 


*¥**** PARAGRAPH NAME MISSING. 
ASSUMED PRESENT, 


INVALID WORD *****, SKIPPING TO 
NEXT RECOGNIZABLE WORD. 


ITEQ1005I- 


ITEQ10061I- 


IEQ1007I- 


IEQ1008I- 


IEQ1009I- 


IEQ1010I- 


IEQ1011I- 


IEQ1012I- 


IEQ1013I- 


IEQ10141- 


IEQ10151I- 


IEQ1016I- 


IEQ10171I- 


IEQ10181I- 


IEQ1019I- 


IEQ1020I- 


TEQ10211- 


IEQ10221- 


IEQ10231I- 


ITEQ1024T- 


IEQ1025I- 


IEQ1026I- 


INVALID ORDER IN ENVIRONMENT 
DIVISION. SKIPPING TO NEXT 
DIVISION. 


DECLARATIVES SECTION WITHOUT USE 
SENTENCE. CONTINUING. 


***** NOT PRECEDED BY A SPACE. 
ASSUME SPACE. 


RIGHT PAREN SHOULD NOT BE PRE- 
CEDED BY SPACE. 


SHOULD BE PRECEDED BY 
IGNORED. 


*INCLUDE* 
PROCEDURE- NAME. 


LEFT PAREN SHOULD NOT BE FOLLOWED 
BY SPACE. 


RECORDING MODE SPECIFICATION IS 
INVALID. ASSUMED VARIABLE. 
FILE-NAME NOT UNIQUE. USING 

FIRST DEFINITION. 


CHARACTER LENGTH IN SPECIAL-NAMES 
SHOULD BE ONE. 


DEVICE SPECIFICATION NOT FOUND IN 
ASSIGN CLAUSE. CONTINUING. 


***** TNVALID AS EXTERNAL-NAME. 
IGNORED. 


MORE THAN ONE ***** CLAUSE. 
SKIPPING TO NEXT CLAUSE. 


*44%% TNVALID IN ***** CLAUSE. 
SKIPPING TO NEXT CLAUSE. 


COPY CLAUSE INVALID IN A COPY 
LIBRARY. IGNORED. 

NO LIBRARY NAME. COPY CLAUSE 

IGNORED. 


****%* SHOULD BE PROCEDURE-NAME 
FOLLOWING *DEBUG. *****, 


***k* DOES NOT BELONG ON *DEBUG 
CARD. SKIPPING TO NEXT CARD. 

PERIOD DOES NOT BELONG ON *DEBUG 
CARD. DELETED. 

INVALID FILE-NAME. USE IGNORED. 

UNDEFINED FILE-NAME. 
IGNORED. 


USE 


REDEFINES CLAUSE NOT FIRST CLAUSE 
FOLLOWING DATA-NAME. ASSUMED 
FIRST. 


SEARCH ASSUMED FOLLOWING 
RESTRICTED. 


IEQ1027I- 
IEQ1028I- 


IEQ1029I- 


IEQ1030I- 


EEQLO311= 


ITEQ1032I- 


IEQ10331I- 
IEQ1034I- 


IEQ1035I- 


IEQ1036I- 


IEQ1037I- 
IEQ1038I- 


IEQ1039I- 


IEQ1040I- 


TEQ1041I- 


IEQ1042I- 
IEQ1043I- 
ITEQ1044I- 


ITEQ1045I- 


IEQ1046I- 


TEQ1047I- 
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RESTRICTED ASSUMED TO PRECEDE 
SEARCH. 


***** SENTENCE IMPROPERLY WRIT- 
TEN. SENTENCE IGNORED. 


*AeKE TN ***** SENTENCE NOT 
DEFINED AS FILE-NAME. NAME 
IGNORED. 


*keKE TN ***** SENTENCE IS INVAL- 
ID. WORD IGNORED. 


USE SENTENCE NOT PRECEDED BY 
SECTION-NAME. SECTION-NAME 
ASSUMED. 


*#**+** TNCORRECTLY USED IN USE 
SENTENCE. SENTENCE IGNORED. 


*#*¥4** FILE-NAME PREVIOUSLY 
ASSIGNED SAME AREA. USING 
FIRST ONE, 


***** CLAUSE ILLEGAL IN ***** 
LEVEL. SKIPPING TO NEXT VALID 
CLAUSE. 


DETAIL NAME NOT UNIQUE. SKIPPING 


TO NEXT 01. 


QUALIFIED NAME INVALID AFTER 
LEVEL NUMBER. USING LOWEST 
NAME. 


***** TNVALID IN DATA DESCRIP- 
TION. SKIPPING TO NEXT CLAUSE. 


****%4# INVALID AFTER LEVEL NUMBER. 
SKIPPING TO NEXT LEVEL. 


****%* CLAUSE NEED 
USING LOWEST 


DATA-NAME IN 
NOT BE QUALIFIED. 
NAME. 


IMPROPER LEVEL NUMBER FOR 
FILE-SECTION. 


**4%** TNVALID AS USED IN ****% 
SECTION. SKIPPING TO NEXT 
LEVEL, SECTION OR DIVISION. 


ASSIGN CLAUSE MISSING IN SELECT. 
CONTINUING. 


END OF SENTENCE SHOULD PRECEDE 
**#4***, ASSUMED PRESENT. 


MISSING DATA RECORDS CLAUSE IN 
FD. 


INVALID ORDER IN ***** SECTION. 


MEMBER NOT FOUND IN LIBRARY. 
IGNORING COPY. 


LIBRARY NOT FOUND ON SYSTEM. 
IGNORING COPY. 
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IEQ1048I- 


ITEQ1049I- 


IEQ1050I- 


IEQ1051I- 


IEQ1052I- 


IEQ10531- 
IEQ10541- 
IEQ10551- 
IEQ1056I- 
IEQ10571- 
ITEQ10581- 
IEQ1059I- 
IEQ1060I- 


IEQ10611I- 
IEQ1062I- 


IEQ10631 
IEQ10641- 
IEQ1065I- 


IEQ1066I- 


IEQ10671- 
IEQ1068I- 


IEQ1069I- 
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LIBRARY MEMBER HAS BAD TRACK. 
IGNORING REST OF COPY. 


**4%** PREVIOUSLY ASSIGNED 
OVERFLOW-NAME. THIS ONE 
DISCARDED. 


****% FILE ALREADY ASSIGNED THIS 
APPLY OPTION. FILE-NAME 
IGNORED. 


NO DATA-NAME IN USE SENTENCE. 
SENTENCE IGNORED. 


****% TLLEGALLY USED IN USE SEN- 
TENCE. END SENTENCE, RESCAN- 
NING AT NEXT RECOGNIZABLE WORD. 

****% CLAUSE INCOMPLETE. CLAUSE 

IGNORED. 


SELECT CLAUSE FOR ***** IGNORED. 
NOT LEGAL FOR SD. 


VALID FILE-NAME NOT PRESENT. 
DESCRIPTION IGNORED. 


FILE-NAME NOT DEFINED IN A 
SELECT. DESCRIPTION IGNORED. 


FIRST WORD IN REPORT SECTION NOT 
RD. IGNORED. 


NO REPORTS CLAUSE IN FILE SEC- 
TION. REPORT SECTION IGNORED. 


NO REPORT CLAUSE FOR RD. RD 


IGNORED. 


INVALID WORD IN RW VERB CLAUSE. 
IGNORED. 


DUPLICATE CLAUSE. DROPPED. 
WORD INVALID AS BCD NAME. 


DUPLICATE ENTRY IN PAGE CLAUSE. 
DROPPED. 


NO TYPE CLAUSE SPECIFIED. 
PING TO NEXT 01. 


SKIP- 


INTEGER MISSING IN PAGE CLAUSE. 
ENTRY IGNORED. 


INVALID WORD IN PAGE CLAUSE. 
SKIPPING TO NEXT RECOGNIZABLE 
WORD. 


INVALID HEADER. SKIPPING TO NEXT 
RECOGNIZABLE WORD. 


OPERAND FOR GENERATE NOT FOUND. 
CLAUSE DROPPED. 


INVALID TYPE CLAUSE. 
NEXT 01. 


SKIPPING TO 


IEQ1070I- 


IEQ10711I- 


IEQ107 21I- 


IEQ107 31I- 


IEQ10741I- 


IEQ1075I- 


IEQ1076I- 


IEQ10771I- 


IEQ1078I- 


IEQ1079I- 


IEQ1080I- 


IEQ10811I- 


IEQ1082I- 


IEQ108 3I- 


ITEQ1084I- 


IEQ1085I- 


TEQ1086I- 


IEQ10871I- 


IEQ1088I- 


IEQ1089I- 


FLT-PT LIT MANTISSA EXCEEDS 16 
DIGITS. TRUNCATED TO 16. 


FLT-PT LIT EXPONENT EXCEEDS 2 
DIGITS. TRUNCATED TO 2. 
RESCANNING. 


FLT-PT LIT EXPONENT FOLLOWED BY 
NON-BLANK. RESCANNING AT 
NON-BLANK. 


FLT-PT LIT E FOLLOWED BY INVALID 
CHARACTER. RESCANNING AT E. 


FLT-PT LIT SIGN FOLLOWED BY 
INVALID CHARACTER. RESCANNING 
AT E. 

FLT-PT LIT EXCEEDS LIMIT. ASSUME 

MAX OR MIN PER SIGN OF 

EXPONENT. 


ALPHANUMERIC LIT EXCEEDS 120 
CHARACTERS. TRUNCATED TO 120. 


ALPHANUMERIC LIT CONTINUES IN 
A-MARGIN. ASSUME B-MARGIN. 


ALPHA-LITERAL CONTINUED WITH 
MISSING HYPHEN OR QUOTE. 
ASSUMED. 


ALPHANUMERIC LIT HAS ZERO LENGTH. 
ASSUME ONE SPACE. 


PERIOD PRECEDED BY SPACE. 
END OF SENTENCE. 


ASSUME 
PERIOD NOT FOLLOWED BY BLANK. 
ASSUME END OF SENTENCE. 


NUMERIC LIT EXCEEDS 18 DIGITS. 
TRUNCATED TO 18. 


ILLEGAL CHARACTER. SCAN RESUMED 
AT NEXT VALID CHARACTER. 


COMMA SHOULD NOT BE PRECEDED BY 


BLANK. ASSUMED OK. 

WORD OR PICTURE EXCEEDS 30 
CHARACTERS. TRUNCATED TO 30 
CHARACTERS. 


*#*%**#* SHOULD BEGIN A-MARGIN. 


***%**#" SHOULD NOT BEGIN 
A-MARGIN. 


MISSING FIRST INSERT OR DELETE 
CARD. PASS CARDS UNTIL FOUND. 
# KEK, 


INSERT OR DELETE NUMBER OUT OF 
SEQUENCE. SKIPPING TO NEXT 


INSERT OR DELETE NUMBER. 
KEK, 


IEQ1090I- 


IEQ10911I- 


IEQ1092I- 


IEQ1093I- 


IEQ1094I- 
IEQ1095I- 


IEQ10971I- 


IEQ1098I- 


IEQ1099I- 


IEQ1100I- 


IEQ11011I- 


IEQ1102I- 


IEQ1103I- 


IEQ11041- 


IEQ1105I- 


IEQ11061- 


IEQ11071- 


IEQ11081- 


IEQ1109I- 


IEQ1110I- 


TEQ11111I- 


IEQ1112I- 


DELETE THRU NUMBER OUT OF 
SEQUENCE. PASS CARDS UNTIL 
NEXT INSERT OR DELETE. ¥****#, 


**%**% TN A-MARGIN NOT VALID AS 
PROC-NM. ASSUME B-MARGIN. 


DECLARATIVES DO NOT FOLLOW PROCE- 
DURE DIVISION. IGNORED. 
NO DECLARATIVES SECTION. END 
DECLARATIVES IGNORED. 
USE STATEMENT INVALID. IGNORED. 
WORD *SECTION* OR ‘DIVISION! 
MISSING. ASSUMED PRESENT. 


PROGRAM-ID MISSING OR MISPLACED. 
IF PROGRAM-ID DOES NOT IMMEDI- 
ATELY FOLLOW IDENTIFICATION 
DIVISION, IT WILL BE IGNORED. 


ALPHA LITERAL NOT CONTINUED WITH 
HYPHEN AND QUOTE. END LITERAL 
ON LAST CARD. 


***** TS INVALID AS USED. 


***** SEQUENCE ERRORS IN SOURCE 
PROGRAM. 


NEXT PAGE NOT IN FIRST LINE 
CLAUSE. IGNORED. 
INCOMPLETE 02 LEVEL. ASSUME 

VALUE SPACES. 


GROUP TYPE ALLOWED ONCE FOR RD. 
IGNORED. 


CONTROL NAME NOT SPECIFIED IN RD. 
SKIPPING TO NEXT 01. 
LEVEL 02 EXPECTED. ASSUMED. 


OPERAND FOR TERMINATE NOT FOUND 
OR ILLEGAL. OPERAND DROPPED. 


ERROR IN PAGE CLAUSE SPECIFICA- 
TIONS. ASSUMING STANDARD 
VALUES. 


**k*k* TS NOT A POSITIVE INTEGRAL 
NUMBER. ASSUMED ONE. 


DUPLICATE USE OF CONTROL NAME. 
SKIPPING TO NEXT 01. 


INVALID USE OF SUM CLAUSE. 
CONTINUING. 


ELEMENTARY LEVEL WITHOUT COLUMN 
OR SUM CLAUSE. WARNING. 


INTEGER OUTSIDE LEGAL LIMITS. 
CONTINUING. 


IEQ1113I- 


IEQ1114I- 


IEQ1115I- 


IEQ11161- 


IEQ1117I- 


IEQ1118I- 


IEQ1119I- 
IEQ1120I- 
IEQ1121I- 


ITEQ1124TI- 


LEQIL2535= 
IEQ1126I- 
IEQ1127I- 
IEQ1128I- 
IEQ2001I- 
IEQ2002I- 
IEQ2003I- 


ITEQ2004I- 


ITEQ2005I- 
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EXPECTING 6-DIGIT SEQUENCE 
NUMBER. SKIPPING TO NEXT 
INSERT OR DELETE NUMBER. 
#EKEK, 


EXTRANEOUS COMMA OR HYPHEN ON 
DELETE CARD. IGNORED. 


NO BLANK, COMMA OR HYPHEN FOLLOW- 
ING SEQUENCE NUMBER. ASSUME 
BLANK. *****, 


EXPECTING 6-DIGIT SEQUENCE NUMBER 
AFTER HYPHEN. IGNORING DELETE 
FROM THRU NUMBER, *****, 


DELETE NUMBER GREATER THAN LAST 
SEQUENCE NUMBER. STOP INSERT 
AND DELETE. *****, 


INSERT NUMBER GREATER THAN LAST 
SEQUENCE NUMBER. STOP INSERT 
AND DELETE. *****, 


*¥**** FEATURE NOT YET IMPLE- 
MENTED. 


COMMA NOT FOLLOWED BY 
ASSUME SPACE. 


BLANK. 


PERIOD OR COMMA INVALID AS USED 
IN PICTURE CLAUSE. 


EXTERNAL-NAME USED OUTSIDE OF 


RERUN CLAUSE. SENTENCE 
IGNORED. . 

NUMBER IS ZERO OR NEGATIVE. SEN- 
TENCE IGNORED. 

NUMBER TOO LARGE FOR RERUN. SEN- 


TENCE IGNORED. 


*** FILE-NAME USED IN PREVIOUS . 
RERUN. USING FIRST ONE. 


*** FILE-NAME PREVIOUSLY SPECI- 
FIED IN RERUN. RERUN IGNORED. 


OPEN OPTION IS ILLEGAL FOR THIS 
ACCESS METHOD. WARNING. 


DEVICE MUST BE DIRECT-ACCESS FOR 
OPEN I-0O. WARNING. 


DEVICE MUST BE DIRECT-ACCESS FOR 
THIS ACCESS METHOD. WARNING. 


RECORDING MODE OPTION ILLEGAL FOR 
THIS ACCESS METHOD. F MODE 
ASSUMED. 


RESERVE CLAUSE ILLEGAL FOR THIS 
ACCESS METHOD OR NUMBER OF 
AREAS IS GREATER THAN 254, 
CLAUSE IGNORED. 
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ITEQ2006I- 


IEQ2007I- 


TEQ2008I- 


IEQ2009I- 


ITEQ2010I- 


IEQ20111- 


IEQ2013I- 


IEQ20141I- 


IEQ2015I- 


IEQ20191I- 


IEQ2020I- 


ITEQ2022I- 


IEQ20231I- 


TEQ20241- 


ITEQ2025I- 


IEQ2026I- 


TEQ20271I- 


ITEQ2028I- 
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BLOCK CONTAINS CLAUSE WITH 
RECORDING MODE 'U* ILLEGAL FOR 
QSAM. CLAUSE IGNORED. 


LABEL RECORDS CLAUSE MISSING OR 
OPTION NOT ‘STANDARD*. 
WARNING. 


APPLY WRITE-ONLY ILLEGAL FOR THIS 
ACCESS METHOD. IGNORED. 


LABEL RECORDS OPTION INCOMPATIBLE 
WITH DEVICE TYPE. WARNING. 


RERUN CLAUSE ILLEGAL FOR THIS 
ACCESS METHOD. CLAUSE IGNORED. 


RERUN CLAUSE ILLEGAL WITH OPEN 
I-O. CLAUSE IGNORED. 


FILE-LIMIT CLAUSE ILLEGAL FOR 
THIS ACCESS METHOD. CLAUSE 
IGNORED. 


FILE-LIMIT SPEC'D AND FILE NOT 
OPENED AS OUTPUT. CLAUSE 
IGNORED. 


APPLY RESTRICTED SEARCH ILLEGAL 
FOR THIS ACCESS METHOD. CLAUSE 
IGNORED. 


BLOCK CONTAINS CLAUSE ILLEGAL FOR 
THIS ACCESS METHOD. CLAUSE 
IGNORED. 


TRACK-AREA CLAUSE ILLEGAL FOR 
THIS ACCESS METHOD. CLAUSE 
IGNORED. 


APPLY OVERFLOW NAME SPEC'D AND 
DEVICE IS NOT A PRINTER. 
WARNING. 


A **#** KEY WAS NOT SPECIFIED FOR 
THIS FILE. WARNING. 


*#k*k% KEY IS ILLEGAL FOR THIS 
ACCESS METHOD. CLAUSE IGNORED. 


WRITE AFTER ADVANCING WAS SPEC'D 
AND FILE WAS NOT OPENED OUTPUT 
OR ACCESS METHOD NOT QSAM. 
WRITES WILL NOT HAVE AFTER 
ADVANCING OPTION FOR THIS FILE. 


CLOSE OPTION CAN ONLY BE SPEC‘'D 
WHEN ORGANIZATION IS STANDARD 
SEQUENTIAL. WARNING. 


TWO DIFFERENT CLOSE OPTIONS WERE 
SPEC'D FOR THIS FILE. WARNING. 


"SAME AREA CLAUSE SPECIFIED FOR 
BSAM RELATIVE TRACK. CLAUSE 
IGNORED. 


IEQ2029I- 


TEQ2030I- 


IEQ2031I- 


IEQ2032I- 


IEQ2033I- 


IEQ2034I- 


IEQ2035I- 


IEQ2036I- 


IEQ2037I- 


IEQ2038I- 


IEQ2039I- 


ITEQ2040I- 


ITEQ2041I-~ 


IEQ2042TI- 


IEQ2043I- 


IEQ2044I- 


IEQ2045I- 


ITEQ2046I- 


IEQ2049I- 


88 ITEM IN SECTION 
THIS ITEM WAS 


FIRST NON 77, 
IS NOT AN 01. 
CHANGED TO 01. 


77 ITEM PRECEDED BY AN 01-49 ITEM 


OR 77 IN FILE SECTION. 77 
CHANGED TO 01. 
88 ITEM PRECEDES 01-49, 77. 8&8 


CHANGED TO 01. 


88 ITEM CONTAINED A CLAUSE OTHER 
THAN VALUE CLAUSE. CLAUSE 
DELETED. 


ITEM'S USAGE INCOMPATIBLE WITH 
USAGE OF GROUP IT BELONGS TO. 
USAGE CHANGED TO GROUP'S USAGE. 


GROUP ITEM HAS PICTURE CLAUSE. 
CLAUSE DELETED. 


GROUP ITEM HAS BLANK WHEN ZERO 
CLAUSE. CLAUSE DELETED. 


GROUP ITEM HAS JUSTIFIED CLAUSE. 
CLAUSE DELETED. 


BLANK WHEN ZERO CLAUSE USED 
INCORRECTLY. CLAUSE IGNORED. 


NUMERIC ITEM HAS BLANK WHEN ZERO 
CLAUSE. ITEM IS CHANGED TO 
REPORT. 


PICTURE CONFIGURATION ILLEGAL. 
PICTURE CHANGED TO 9 UNLESS 
USAGE IS ‘DISPLAY-ST', THEN 
L(6) BDZ9BDZ9. 


JUSTIFIED CLAUSE SPEC'D FOR NON- 
ALPHABETIC OR NON-ALPHANUMERIC 
ITEM. CLAUSE DELETED. 


CONDITIONAL VARIABLE IS A GROUP 
ITEM. CHANGED TO ELEMENTARY 
ITEM. 


THIS ITEM CAUSES OVER 3 LEVELS OF 
SUBSCRIPTING. OCCURS CLAUSE 
DROPPED FOR THIS ITEM. 


01 LEVEL HAS AN OCCURS CLAUSE. 
CLAUSE DELETED. 


FILLER IS USED AS A CONDITIONAL 
VARIABLE. CONDITION NAMES 
UNDER IT ARE DELETED. 

REPORT CONTROL NAME UNDEFINED. 


REPORT CONTROL NAME NOT FIXED 
LENGTH. 


NO OPEN CLAUSE FOUND FOR FILE. 
WARNING. 


IEQ20501I- 


IEQ20511I- 


IEQ20531I- 


IEQ20541I- 


ITEQ20551I- 


IEQ2056I- 


ITEQ20571I- 


ITEQ2058I- 


IEQ2059I- 


ITEQ2060I- 


IEQ2061I- 


IEQ2062I- 


IEQ2063I- 


IEQ2064I- 


IEQ2065I- 


IEQ2066I- 


IEQ20671I-~ 


BLOCK SIZE GREATER THAN 32760. 
WARNING - CANNOT WRITE BLOCK OF 
THIS SIZE. 


TRACK AREA DATA-NAME IS NON- 
UNIQUE OR UNDEFINED. CLAUSE 
IGNORED. 


KEY IS NON-UNIQUE OR UNDEFINED. 
CLAUSE IGNORED. 


SYMBOLIC KEY PICTURE OR USAGE NoT 
LEGAL. 


STERLING NON~REPORT PICTURE - 
SIGN IN POUND FIELD MUST BE ON 
HI OR LO ORDER DIGIT. PICTURE 
REPLACED BY 9D8D7. 


STERLING NON-REPORT PICTURE - 9 
IN ILLEGAL POSITION. PICTURE 
REPLACED BY 9D8D7. 


STERLING NON-REPORT PICTURE - 
SIGN IN SHILLING FIELD ILLEGAL. 
PICTURE REPLACED BY 9D8D7. 


STERLING NON-REPORT PICTURE - 8 
IN ILLEGAL POSITION. PICTURE 
REPLACED BY 9D8D7. 


STERLING NON-REPORT PICTURE - 
SIGN IN PENCE FIELD ILLEGAL. 
PICTURE REPLACED BY 9D8D7. 


STERLING NON-REPORT PICTURE - 6 


OR 7 IN ILLEGAL POSITION. PIC- 

TURE REPLACED BY 9D8D7. 
STERLING NON-REPORT PICTURE - 

USAGE NOT DISPLAY-ST. PICTURE 


REPLACED BY 9(1). 


STERLING NON-REPORT PICTURE - V 
IN ILLEGAL POSITION. PICTURE 
REPLACED BY 9D8D7. 


STERLING NON-REPORT PICTURE - S 
IN ILLEGAL POSITION. PICTURE 
REPLACED BY 9D8D7. 


STERLING NON-REPORT PICTURE - 
DIGIT LENGTH GT 18. PICTURE 
REPLACED BY 9D8D7. 


STERLING NON-REPORT PICTURE - 
SHILLING FIELD GT 2. PICTURE 
REPLACED BY 9D8D7. 


STERLING NON-REPORT PICTURE - 
PENCE FIELD GT 2. PICTURE 
REPLACED BY 9D8D7. 


STERLING NON-REPORT PICTURE - NO 
POUND SEPARATOR. PICTURE 
REPLACED BY 9D8D7. 


IEQ2068I- 


IEQ2069I- 


IEQ2070I- 


IEQ2071I- 


IEQ2072I- 


IEQ2073I- 


IEQ2074I- 


IEQ2075I- 


IEQ2076I- 


IEQ20771I- 


IEQ2078I- 


ITEQ2079I- 


IEQ2080I- 


IEQ20811I- 


IEQ208 2I- 


IEQ2083I- 


TEQ20841- 
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STERLING NON-REPORT PICTURE - NO 
SHILLING SEPARATOR. PICTURE 
REPLACED BY 9D8D7. 


NUMERIC PICTURE - SIGN IN ILLEGAL 
POSITION. PICTURE REPLACED BY 
9(1). 


NUMERIC PICTURE - P IN ILLEGAL 
POSITION. PICTURE REPLACED BY 
9(1). 


NUMERIC PICTURE - V IN ILLEGAL 


POSITION. PICTURE REPLACED BY 
9(1). 

NUMERIC PICTURE - NO 9 IN PIC- 
TURE. PICTURE REPLACED BY 
9(1). 

NUMERIC PICTURE - P ENCLOSED BY 
9°S. PICTURE REPLACED BY 9(1). 


NUMERIC PICTURE ~ NO SIGN ON 
BINARY ITEM. ASSUMED SIGN 
PRESENT. 


NUMERIC PICTURE - DIGIT LENGTH GT 
18. PICTURE REPLACED BY 9(1). 


NUMERIC PICTURE - DIGIT LENGTH + 
SCALE GT 18. PICTURE REPLACED 
BY 9(1). 


EXTERNAL FLOATING-POINT PICTURE - 
USAGE NOT DISPLAY. PICTURE 
CHANGED TO 9. 


EXTERNAL FLOATING-POINT PICTURE - 
SIGN COUNT NOT ONE. CHANGED TO 
As 


EXTERNAL FLOATING-POINT PICTURE - 
SIGN IN ILLEGAL POSITION. PIC- 
TURE CHANGED TO +9.Et99, 


EXTERNAL FLOATING-POINT PICTURE - 
SIGN MISSING. ASSUME MINUS 
SIGN. 


EXTERNAL FLOATING-POINT PICTURE - 
REQUIRED CHARACTER BEFORE 
EXPONENT MISSING. PICTURE 
CHANGED TO +9.E+99. 


EXTERNAL FLOATING-POINT PICTURE - 
NO DECIMAL-POINT IN MANTISSA. 
ASSUME IMPLIED V. 


EXTERNAL FLOATING-POINT PICTURE - 
MANTISSA LENGTH GT 16. PICTURE 
CHANGED TO +9.E+99. 


EXTERNAL FLOATING-POINT PICTURE - 


TOTAL LENGTH GT 21. PICTURE 
CHANGED TO +9.E+99, 
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ITEQ2085I- 


IEQ2086I- 


ITEQ20871I- 


IEQ2088I- 


IEQ2089I- 


IEQ2090I- 


IEQ2091I- 


IEQ2092I- 


IEQ2093I- 


IEQ2094I- 


ITEQ2095I- 


IEQ2096I- 


IEQ20971I- 


IEQ2098I- 


IEQ2099I- 


IEQ2100I- 


IEQ21011I- 
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EXTERNAL FLOATING-POINT PICTURE - 
EXPONENT LENGTH NOT 2 DIGITS. 
ASSUME 2 DIGITS. 


REPORT PICTURE - TWO FIXED DOLLAR 
SIGNS, +, - OR FIXED AND FLOAT- 
ING DOLLAR SIGN. PICTURE 
REPLACED BY 9(1). 


REPORT PICTURE - SIGN PRECEDES 
FIXED DOLLAR SIGN. PICTURE 
REPLACED BY 9(1). 


REPORT PICTURE - FIXED SIGN PRE- 


CEDES FLOATING STRING. PICTURE 
REPLACED BY 9(1). 

REPORT PICTURE - 9, Z OR * PRE- 
CEDES FLOATING STRING. PICTURE 


REPLACED BY 9(1). 


REPORT PICTURE - P IN ILLEGAL 
POSITION. PICTURE REPLACED BY 
9(1). 


REPORT PICTURE - TWO DIFFERENT 
FLOATING STRING CHARACTERS. 
PICTURE REPLACED BY 9(1). 


REPORT PICTURE - Z AND * IN PIC- 
TURE. PICTURE REPLACED BY 
9(1). 


REPORT PICTURE - 9 PRECEDES * OR 
Ze PICTURE REPLACED BY 9(1). 


REPORT PICTURE - FLOATING STRING 
PRECEDES * OR Z PICTURE 
REPLACED BY 9(1). 


NUMBER OF CHARACTERS IN BLOCK 
CONTAINS CLAUSE ON FORMAT F 
FILE NOT MULTIPLE OF RECORD 
LENGTH. ASSUMING BLOCK SIZE TO 
BE CLOSEST MULTIPLE. 


REPORT PICTURE - TWO DECIMAL 
POINTS. PICTURE REPLACED BY 
9(1). 


REPORT PICTURE - DECIMAL POINT OR 
V CONTRADICTORY TO Pe. PICTURE 
REPLACED BY 9(1). 


REPORT PICTURE - CR AND DB BOTH 
USED. PICTURE REPLACED BY 
9(1). 


REPORT PICTURE - CR OR DB AND 
SIGN BOTH USED. PICTURE 
REPLACED BY 9(1). 


REPORT PICTURE - CR OR DB NOT 
LAST TWO CHARACTERS IN PICTURE. 
PICTURE REPLACED BY 9(1). 


REPORT PICTURE - SIGN IS NOT 
FIRST OR LAST CHARACTER IN PIC- 


IEQ2102I- 


IEQ2103I- 


IEQ2104I- 


IEQ2105I- 


IEQ2106I- 


IEQ2107I- 


TEQ2109I- 


IEQ2110I- 


IEQ2111I- 


IEQ2113I- 


IEQ2115I- 


IEQ2116I- 


IEQ2117I- 


IEQ2118I- 


IEQ2119I- 


ITEQ2120I- 


IEQ2121I- 


TURE. PICTURE REPLACED BY 


9(1). 


REPORT PICTURE - NUMERIC CHARAC- 
TERS AFTER DECIMAL POINT ARE 
NOT THE SAME. PICTURE REPLACED 
BY 9(1). 


REPORT PICTURE - TOTAL LENGTH GT 
127. PICTURE REPLACED BY 9(1). 


REPORT PICTURE - NUMERIC LENGTH 
GT 18. PICTURE REPLACED BY 
9(1). 


REPORT PICTURE - NO NUMERIC 
CHARACTERS IN PICTURE. PICTURE 
REPLACED BY 9(1). 


REPORT PICTURE - BLANK WHEN ZERO 
CLAUSE SPEC'D FOR ALL *'S. 
PICTURE REPLACED BY 9(1). 


REPORT PICTURE - USAGE NOT DIS- 
PLAY. PICTURE CHANGED TO 9. 


TRACK-AREA INTEGER NOT MULTIPLE 
OF 8. ROUNDED DOWN TO MULTIPLE 
OF 8. 


APPLY WRITE-ONLY CLAUSE ILLEGALLY 
USED. IGNORED. 


RECORDING MODE V NOT IMPLEMENTED 
FOR INDEXED FILES. SUBSTITUT- 
ING F. 


ITEM WITH USAGE OF COMPUTATIONAL- 
1 OR COMPUTATIONAL-2 HAS PIC- 
TURE CLAUSE. CLAUSE IGNORED. 


GROUP ITEM SIZE IS GT 32K. 
WARNING. 


FIXED LENGTH GROUP ITEM IN 
WORKING-STORAGE SECTION IS GT 
131K. WARNING. 


THE OBJECT OF REDEFINES CLAUSE IS 
A VARIABLE LENGTH ITEM. 
WARNING. 


LENGTH OF REDEFINES SUBJECT 
GREATER THAN LENGTH OF REDE- 
FINES OBJECT. SUBJECT LENGTH 
USED - WARNING. 


VALUE CLAUSE SPECIFIED FOR AN 
ITEM IN A REDEFINES GROUP. 
CLAUSE IGNORED. 


OBJECT OF REDEFINES CLAUSE UNDE- 
FINED OR ILLEGAL. CLAUSE 
IGNORED. 


SUBJECT OF REDEFINES IS VARIABLE 
LENGTH. WARNING. 


IEQ2122I- 


IEQ2123I- 


IEQ2124I- 


IEQ2125I- 


IEQ2126I- 


IEQ21271I- 


IEQ2128I- 


ITEQ2129I- 


IEQ2130I- 


IEQ2131I- 


IEQ2132I- 


ITEQ2133I- 


IEQ21341I- 


IEQ2135I- 


IEQ2136I- 


IEQ21371I- 


IEQ21381- 


IEQ21411I- 


IEQ2142I- 


TEQ2143I- 


REDEFINES SUBJECT LEVEL NUMBER 
NOT EQUAL TO REDEFINES OBJECT 
LEVEL NUMBER. CLAUSE IGNORED. 

OBJECT OF REDEFINES IS SUB- 

SCRIPTED. 


OBJECT OF REDEFINES IS VARIABLE 
LENGTH GROUP ITEM. WARNING. 


VALUE CLAUSE LEGAL ONLY FOR 88 
ITEMS IN FILE SECTION AND LINK- 
AGE SECTION. CLAUSE IGNORED. 


VALUE CLAUSE LITERAL TOO LONG. 
TRUNCATED TO PICTURE SIZE. 


VALUE CLAUSE SPECIFIED FOR GROUP 
ITEM. CLAUSE IGNORED. 


VALUE CLAUSE LITERAL DOES NOT 


CONFORM TO PICTURE. CHANGED TO 
BLANKS. 

VALUE CLAUSE LITERAL DOES NOT 
CONFORM TO PICTURE. CHANGED TO 
ZERO. 

ITEM CANNOT HAVE VALUE CLAUSE. 


CLAUSE IGNORED. 


RECORD KEY UNDEFINED OR NON- 
UNIQUE. KEY IGNORED. 


RECORD KEY LENGTH GREATER THAN 
255 BYTES. USING FIRST 255 
BYTES. 


LABEL RECORDS CLAUSE MISSING. 


VALUE FOR SCALING CHARACTER 
SHOULD BE ZERO. CHANGED TO 
ZERO. 


OVERFLOW-NAME ON FILE WITH 
ALTERNATE AREAS SPECIFIED OR 
RESERVE CLAUSE OMITTED. 


SYMBOLIC KEY LENGTH GREATER THAN 
255 BYTES. KEY IGNORED. 


ACTUAL KEY NOT S9(5) COMPUTATION- 
AL. KEY IGNORED. 


ITEM LENGTH GREATER THAN 32K. 
TRUNCATED TO 32K. 


QISAM FILE OPENED OUTPUT MAY NOT 
ALSO BE OPENED INPUT OR I-O. 
PROGRAM INTERRUPT WILL OCCUR. 


ALPHABETIC OR ALPHANUMERIC ITEM 
HAS ILLEGAL USAGE. PICTURE 
CHANGED TO 9. 


STERLING NON-REPORT PICTURE - 
COUNT OF V OR S NOT ONE. 
ASSUMED ONE. 


TEQ2144I- 


IEQ2145I- 


ITEQ21461I- 


IEQ21471I- 


ITEQ2148I- 


TEQ2149I- 


IEQ2150I- 


IEQ2151I- 


IEQ2152I- 


IEQ2153I- 


IEQ2154I- 


IEQ2155I- 


IEQ2156I- 


IEQ2157I- 


IEQ2158I- 
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NUMERIC PICTURE - COUNT OF V OR S 
NOT ONE. ASSUMED ONE. 


ALPHABETIC OR ALPHANUMERIC ITEM 
LENGTH GREATER THAN 32767. 
TRUNCATED TO 32767. . 


RECORD SIZE IN RECORD-CONTAINS 
CLAUSE DISAGREES WITH COMPUTED 
RECORD SIZE. USING MAXIMUM 
COMPUTED SIZE.’ 

"RECORD CONTAINS INTEGER-1' IS 

NOT MINIMUM. 


ON AN 01(77) COPY LIBRARY-NAME 
CLAUSE, LIBRARY DID NOT HAVE AN 
01(77) AS FIRST CARD. WARNING, 


VALUE CLAUSE SPECIFIED FOR ITEM 
WITH OCCURS OR FOR ITEM SUBOR- 
DINATE TO AN ITEM WITH OCCURS. 
CLAUSE IGNORED. 


VALUE CLAUSE SPECIFIED FOR ITEM 
IN VARIABLE LENGTH PORTION OF A 
WORKING-STORAGE RECORD. CLAUSE 
IGNORED. 


ELEMENTARY ITEMS NOT INTERNAL 
FLOATING-POINT MUST HAVE PIC- 
TURE. PICTURE ASSUMED 9. 


COMPILER ERROR - PHASE 2 INPUT 
UNRECOGNIZABLE. SKIPPING TO 


NEXT PHASE. 


DATA-NAME OF TRACK-AREA CLAUSE IS 
NOT AN ITEM OF LEVEL 01 OR 77 
IN WORKING STORAGE. CLAUSE 
IGNORED. 


THE AREA BEING REDEFINED IS NOT 
IMMEDIATELY PRECEDING THE ENTRY 
WHICH REDEFINES IT OR THE LEVEL 
NUMBERS OF THE SUBJECT AND 
OBJECT OF THE REDEFINES ARE NOT 
THE SAME. THE OBJECT OF THE 
REDEFINES IS ASSUMED TO BE THE 
LAST ENTRY WITH SAME LEVEL 
NUMBER AS SUBJECT OF REDEFINES. 


ILLEGAL STERLING NON-REPORT PIC- 
TURE CHARACTER. PICTURE 
REPLACED BY 9D8D7. 


PICTURE DOES NOT CONTAIN A SIGN. 
SIGN DROPPED FROM VALUE CLAUSE 
LITERAL. 


SYMBOLIC KEY FOR A RELATIVE 
ORGANIZATIONAL FILE MUST BE 
S9(8) COMPUTATIONAL. WARNING. 


OCCURS DEPENDING ON VARIABLE IS 
IN VARIABLE PORTION OF A 
RECORD. PROGRAM INTERRUPT WILL 
OCCUR. 
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IEQ2159I- 


IEQ21601I- 


IEQ21611I- 


IEQ21621- 


IEQ2163I- 


IEQ21641- 


IEQ2165I- 


IEQ2166I- 


IEQ21671I- 


IEQ2168I- 


IEQ21691I- 


IEQ2170I- 


IEQ21711- 


ITEQ2172I- 


IEQ21731I- 


IEQ2174I- 
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A SEQUENTIAL FILE NAMED UNDER A 
SAME AREA CLAUSE MUST HAVE A 
RESERVE CLAUSE ASSOCIATED WITH 
IT. CLAUSE IGNORED. 


"RECORD CONTAINS INTEGER-2' IS 
USED FOR RECORD LENGTH SINCE 
THERE WERE TWO OR MORE VARIABLE 
LENGTH ITEMS IN THE RECORD. 
WARNING. 


PICTURE INVALID. ADJACENT C 
DELIMITERS. ASSUMED PICTURE 
L(6) 9BDZ9BD29. 


PICTURE INVALID. ADJACENT D 
DELIMITERS. ASSUMED PICTURE 
L(6) 9BDZ9BDZ9. 


PICTURE INVALID. MORE THAN 2 
DELIMITERS. ASSUMED PICTURE 
L(6) 9BDZ9BDZ9. 


PICTURE INVALID. NO STERLING 
DELIMITERS. ASSUMED PICTURE 
L(6) 9BDZ9BDZ9. 


PICTURE INVALID. ONLY 1 STERLING 
DELIMITER. ASSUME PICTURE 
L(6) 9BDZ9BDZ9. 


PICTURE INVALID. ERROR IN SHIL- 
LING FIELD. ASSUMED SHILLING 
PICTURE Z9B. 


NUMBER OF POUND 
ASSUMED 


PICTURE INVALID. 
DIGITS EXCEEDS 15. 
PICTURE L(6) 9BD. 


ERROR IN WHOLE 
ASSUMED PENCE 


PICTURE INVALID. 
PENCE FIELD. 
PICTURE Z9. 


ERROR IN DECIM- 
DECIMAL FIELD 


PICTURE INVALID. 
AL PENCE FIELD. 
TRUNCATED. 


PICTURE INVALID. ERROR IN POUND 
FIELD. ASSUMED POUND PICTURE 
L(6) 9B. 


PICTURE INVALID. NUMBER OF POUND 
DIGITS PLUS NUMBER OF PENCE 
DECIMAL EXCEEDS 15. DECIMAL 
PENCE DROPPED. 


PICTURE INVALID. SIZE OF REPORT 
FIELD EXCEEDS 127 BYTES. 
ASSUMED PICTURE L(6) 9BDZ9BDZ9. 


PICTURE INVALID. CR OR DB NOT 
VALID WITH LEADING SIGN. 
DECIMAL FIELD TRUNCATED. 


PICTURE INVALID. SIGN IN DECIMAL 
PENCE FIELD NOT VALID WITH 
LEADING SIGN. DECIMAL FIELD 
TRUNCATED. 


IEQ2175I- 


IEQ2176I- 


IEQ21771I- 


IEQ2178I- 


IEQ2179I- 


ITEQ2180I- 


IEQ2181I- 


IEQ218 2I- 


IEQ2183I- 


TEQ2184I- 


IEQ2186I- 


IEQ2188I- 


IEQ2189I- 


IEQ30011I- 


IEQ3002I- 


IEQ3003I- 


TRACK-AREA EXCEEDS AND IS REDUCED 
TO 32,760 BYTES. 


DATA-NAME OF TRACK-AREA CLAUSE 
EXCEEDS 32,767 BYTES IN LENGTH. 
CLAUSE IGNORED. 


DATA-NAME OF TRACK-AREA CLAUSE IS 
NOT FIXED-LENGTH. CLAUSE 
IGNORED. 


RECORD-KEY IS NOT WITHIN 
FILE~RECORD. 


RECORD~-KEY IS NOT FIXED-LENGTH. 


RECORD-KEY FOR UNBLOCKED FILE 
INCLUDES FIRST BYTE OF RECORD. 


SYMBOLIC OR ACTUAL KEY IS DEFINED 
WITHIN THE FILE. 


APPLY WRITE ONLY IS MEANINGLESS 
WHEN RECORDING MODE IS F. 
CLAUSE IGNORED. 


NO LEVEL 01 FOR FD. 


VALUE CLAUSE LITERAL DOES NOT 
CONFORM TO PICTURE. CLAUSE 
IGNORED. 


PICTURE DUPLICATION FACTOR IS 
ZERO. ASSUMING ONE OCCURRENCE 
OF PICTURE CHARACTER. 


BLOCK CONTAINS 0 RECORDS. BLOCK- 
SIZE MUST BE SPECIFIED IN DD 
CARD. 


BLOCK CONTAINS 0 RECORDS INCOM- 
PATIBLE WITH SAME AREA CLAUSE 
OR FOR BISAM. CLAUSE IGNORED. 


***** NOT DEFINED. 


Explanation: This message always 
appears in conjunction with 
another message. 


***+* NOT UNIQUE. 


Explanation: This message always 
appears in conjunction with 
another message. 


HIGHEST LEVEL QUALIFIER ***** NOT 
DEFINED. 


Explanation: This message always 
appears in conjunction with 
another message. 


IEQ3004I- 


IEQ3005I- 


IEQ3006I- 


ITEQ30071I- 


TEQ3008I- 


IEQ3009I- 


IEQ3010I- 


ITEQ3011I- 


IEQ3012I- 


IEQ30131I- 


ITEQ30141- 


IEQ3015I- 


IEQ3016I- 


IEQ3017I- 


IEQ3019I- 


ITEQ3020I- 


ITEQ4001I- 


HIGHEST LEVEL QUALIFIER ***** NOT 
UNIQUE. 


Explanation: This message always 
appears in conjunction with 
another message. 


****£* NOT A VALID QUALIFIER. 


Explanation: This message always 
appears in conjunction with 
another message. 


****%- NOT DEFINED AS PART OF 
RA, 


Explanation: This message always 
appears in conjunction with 
another message. 


**%*4% NOT UNIQUELY QUALIFIED BY 
we RAK 


Explanation: This message always 
appears in conjunction with 
another message. 


*#**** NOT VALID AS DATA-NAME-1 IN 
***** CORRESPONDING STATEMENT. 


*4*%44+%* NOT VALID AS DATA-NAME-2 IN 
***#** CORRESPONDING STATEMENT. 


SUPERFLUOUS ‘TO* IGNORED IN *#**+#* 
CORRESPONDING STATEMENT. 


NO CORRESPONDENCE FOUND BETWEEN 
DATA-NAME-1 AND *****, 


NO MATCHED DCB IN QFILE TABLE FOR 
FILE *****, 


DICT PTR LESS THAN QVAR ENTRY FOR 
ELEMENTARY ITEM. 


NO MATCH FOUND IN QVAR FOR ***#** 
ELEMENTARY ITEM. 


Q ON, DELIMITER GROUP NAME ***** 
NOT FOUND. 
IMPOSSIBLE *****, COMPILER 
ERROR. 
COMPILER ERROR. ¥***** MINOR CODE 
ILLEGAL. 


ILLEGAL LEVEL FOR *****, 


REPORT NAME ILLEGAL AS USED. 
DISCARDED. 


OUTCOME OF A PRECEDING CONDITION 
LEADS TO NON-EXISTENT ‘NEXT 
SENTENCE’. ‘STOP RUN’ 
INSERTED. 


ITEQ4002I- 
IEQ4003I- 


IEQ4004I- 


IEQ4OO5I- 
IEQ4006I- 
IEQ4007I- 


IEQ4O08I- 


TEQ4009T- 


IEQ4010I- 
ITEQ4011I- 


IEQ4012I- 
IEQ4013I- 
ITEQ4014I- 
TEQ4015I- 


ITEQ4016I- 


IEQ4017I- 


ITEQ4018I- 


ITEQ4019I- 
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*#*#4* STATEMENT INCOMPLETE. 
STATEMENT DISCARDED. 


EXPECTING NEW STATEMENT. FOUND 
**44*, DELETING TILL NEXT VERB 
OR PROCEDURE NAME. 


¥AKEE/*EEKE TS ILLEGALLY USED IN 
****% STATEMENT. DISCARDED. 


**4%4 AND ***** VIOLATE RULE 
ABOUT LENGTH OF TRANSFORM 
OPERANDS. STATEMENT DISCARDED. 


***** STATEMENT CONTAINS UNPAIRED 
LEFT PARENTHESES. OUTERMOST 
IGNORED. 


*¥**** MISSING OR MISPLACED IN 
****#* STATEMENT. ASSUMED IN 
REQUIRED POSITION. 


SUPERFLUOUS ***** FOUND IN **#*** 
STATEMENT. IGNORED. 


EXAMINE STATEMENT REQUIRES 
FIGURATIVE CONSTANT OR SINGLE 
ALPHANUMERIC CHARACTER. 
FOUND ***#*, STATEMENT 
DISCARDED. 


*¥**** STATEMENT CONTAINS UNPAIRED 
RIGHT PARENTHESES. OUTERMOST 
IGNORED. 


*#***#* TS NOT AN ALLOWABLE 
CHARACTER FOR *****. STATEMENT 
DISCARDED. 


COMPARISON BETWEEN TWO LITERALS 
IS ILLEGAL. TEST DISCARDED. 


RELATIONAL MISSING IN IF STATE- 
MENT. ‘*EQUAL' ASSUMED. 


EXAMINE STATEMENT REQUIRES DATA- 
NAME WHOSE USAGE IS DISPLAY. 


FOUND ***#4*/**4**, STATEMENT 
DISCARDED. 

*GO TO .* IS ILLEGAL UNLESS 
ALTERED SOMEWHERE. STATEMENT 
DISCARDED. 


OPERAND OF ***** APPEARS IN WRONG 
SEGMENT OF PROGRAM. STATEMENT 
ACCEPTED AS WRITTEN. 


ELSE UNMATCHED BY CONDITION IS 
DISCARDED. 


*ALL' MUST BE FOLLOWED BY SINGLE 
ALPHANUMERIC CHARACTER. FOUND 
*#%*44, ‘ALL' DISCARDED. 


#4444 /¥444% MAY NOT BE USED AS 
ARITHMETIC OPERAND IN ***** 
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IEQUO20I- 


ITEQ4021I- 


TEQ4022I- 


IEQ4023I- 


ITEQ&O24I- 


ITEQ4026I- 


IEQ4027I- 


ITEQ4O28I- 


ITEQ4O029I- 


IEQ4030I- 


ITEQ4031I- 


IEQ4032I- 


ITEQ4033I- 


IEQ4034I1- 


IEQ4035I- 
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STATEMENT. ARBITRARILY SUBSTI- 
TUTING **4#%**, 
SIGN BEFORE ***** TS DISCARDED. 
MINUS SIGN FOLLOWED BY SPACE 


ACCEPTED AS REVERSING SIGN OF 
FOLLOWING LITERAL. 


EXIT MUST BE SINGLE-WORD PARA- 
GRAPH PRECEDED BY A PROCEDURE- 
NAME. STATEMENT DISCARDED. 


SYNTAX REQUIRES STORE-FIELD TO BE 
A REPORT ITEM OR NUMERIC DATA- 
NAME. FOUND ***#4#/* 4444, 
STATEMENT DISCARDED. 


TWO OPERANDS ARE REQUIRED BEFORE 
*GIVING'. STATEMENT DISCARDED. 


*e4KE/*KEKE* TS ILLEGALLY USED IN 
*¥*¥4*4% TEST. TEST DISCARDED. 


RIGHT TERM OF A CONDITION MAY NOT 
BE NEGATED. NEGATION IS 
APPLIED TO THE RELATIONAL. 


TWO *‘NOT'S' IN SUCCESSION 
ILLEGAL. ACCEPTED AS CANCEL- 
LING EACH OTHER. 


*XKEE/*4KEX MAY NOT BE COMPARED 
WITH ****4/4*4**, TEST 
DISCARDED. 


SYNTAX REQUIRES 'OR', ‘AND', OR 
VERB AFTER CONDITION. FOUND 
**4#%, DELETING TILL ONE OF 
THESE IS FOUND. 


PROCEDURE-NAME NOT THAT OF A 
SINGLE GO PARAGRAPH MAY NOT BE 
ALTERED. STATEMENT DISCARDED. 


NO ACTION INDICATED IF PRECEDING 
CONDITION IS TRUE. STATEMENT 
ACCEPTED WITH TRUE AND FALSE 
OUTCOMES IDENTICAL. 


PROCEDURE-NAME WHICH IS THE END- 
OF-RANGE OF A PERFORM STATEMENT 
MAY NOT BE ALTERED. STATEMENT 
DISCARDED. 


GO DEPENDING ON MUST BE FOLLOWED 
BY INTEGRAL DATA-NAME LESS THAN 
4 DIGITS IN LENGTH. FOUND 
*4*4***, STATEMENT DISCARDED. 


COBOL LANGUAGE FORBIDS VARYING 
MORE THAN 3 DATA-NAMES. STATE- 
MENT ACCEPTED AS WRITTEN. 


Explanation: This compiler can 
normally handle a program varying 
more than three data-names, but 
the practice is invalid under 


ITEQ4036I- 


IEQ4037I- 


IEQUO38I- 


IEQ4039I- 


ITEQ4O4OI- 


IEQUO4II- 


TEQ4O42TI- 


IEQ4043I- 


TEQUO44T= 


ITEQ4O4SI- 


IEQ4O46I- 


IEQUO47I- 


IEQUO48I- 


TEQ4O049T- 


IEQ4O50I- 


standard COBOL language rules and 
is not recommended. 


PERFORM RANGE IS FROM ***** TO ** 
***, WHICH PRECEDES IT. STATE- 
MENT ACCEPTED AS WRITTEN. 


Ex This compiler can 
normally handle the perform range 
indicated, but the practice is 
not recommended. 


SYNTAX REQUIRES PROCEDURE-NAME TO 
FOLLOW 'THRU*'. FOUND ****#*, 
***** OPTION DISCARDED. 


VARYING OPTION REQUIRES NUMERIC 
DATA-NAME. FOUND LITERAL. 
ARBITRARILY SUBSTITUTING ***** 


+4##44/4444* IN VARYING OPTION IS 
NOT NUMERIC. ARBITRARILY SUB- 
STITUTING **#***, 


¥*444% FILE ***** MAY NOT BE 
OPENED ***** AND IS DISCARDED. 


SYNTAX .REQUIRES ‘INPUT’, ‘OUT- 
PUT, OR ‘I-O* AFTER OPEN. 
FOUND ***##, DELETING TILL ONE 
OF THESE IS FOUND. 


SYNTAX REQUIRES FILE-NAME IN 
*¥*4**% STATEMENT. FOUND *****, 
DELETING TILL LEGAL ELEMENT 
FOUND. : 


**4** TS AN ILLEGAL OPERAND FOR 
***** IN THIS PORTION OF PRO- 
GRAM. DISCARDED. 


INVALID KEY OPTION ILLEGAL FOR 
*#***, FOR WHICH AN ERROR 
DECLARATIVE EXISTS. DISCARDED. 


‘AFTER ADVANCING® REQUIRES 1- 
CHARACTER ALPHANUMERIC DATA- 
NAME OR INTEGER LESS THAN 3. 
FOUND *****, SUBSTITUTING 
RAKE, 


ILLEGAL TO ***4#*/**4#%** FILE 
***#*,. STATEMENT DISCARDED. 


****%* STATEMENT MAY NOT APPEAR IN 
THIS DECLARATIVE SECTION. STA- 
TEMENT DISCARDED. 


USE VERB MAY NOT APPEAR EXCEPT IN 
DECLARATIVES SECTION. STATE- 
MENT DISCARDED. 


INAPPROPRIATE OPTIONAL COBOL 
WORDS PRECEDING *#**** IGNORED. 


SYNTAX REQUIRES **#**, FOUND 
*#%**#4,. STATEMENT DISCARDED. 


TEQ4052I- 


IEQ4O54I- 


ITEQ4O55I- 


IEQU056I- 


IEQ4057I- 


ITEQ4058I- 


IEQ4059I- 


ITEQ4060I- 


IEQ40611I- 


TEQ4062I- 


TEQ4063I- 


ITEQSO64T- 


ITEQ4065I- 


IEQ4066I- 


IEQ4067I- 


IEQ4068I- 


eke e/*EKEE MAY NOT BE TARGET 
FIELD FOR *###k/4#4#44 JN #4444 
STATEMENT, AND IS DISCARDED. 


SYNTAX REQUIRES SORT-FILE NAME. 
FOUND **#***#, STATEMENT 
DISCARDED. 


SORT SEQUENCE NOT SPECIFIED. 
ASCENDING ASSUMED. 
SYNTAX REQUIRES *****, FOUND 

¥*¥#***, DISCARDED. 


SORT-KEYS LIMITED TO 12 OR TO 256 
BYTES. ***** DISCARDED. 


SYNTAX REQUIRES ‘USING (‘GIV- 
ING') TO BE FOLLOWED BY FILE- 
NAME DEFINED UNDER AN FD. 
FOUND *****, STATEMENT 
DISCARDED. 


SORT-KEY MUST BE NON-SUBSCRIPTED 
FIXED-LENGTH DATA-NAME DEFINED 
UNDER AN SD. FOUND *****, 
DISCARDED. 


*¥*#4**% TS NOT A POSITIVE NUMERIC 
INTEGRAL LITERAL OF REQUIRED 
LENGTH. ***** OPTION 
DISCARDED. 


NEITHER NAMED NOR CHANGED SPECI- 
FIED. STATEMENT ACCEPTED. 
WILL BE TREATED AS FORMATTED 
DISPLAY. 


"NAMED CHANGED’ ACCEPTED AS 
"CHANGED NAMED‘. 


PREVIOUS DEBUG PACKET REFERS TO 
SAME PROCEDURE-NAME. CARD 
DELETED AND FOLLOWING STATE- 
MENTS ATTACHED TO IMMEDIATELY 
PRECEDING PACKET. 


**44% TS NOT A POSITIVE NUMERIC 
INTEGRAL LITERAL OF REQUIRED 
LENGTH. SUBSTITUTING ****%*, 


ENTER LINKAGE DOES NOT PRECEDE 
*#*#4* STATEMENT. ASSUMED. 


SYNTAX REQUIRES 01 LEVEL SD DATA- 
NAME IN RELEASE STATEMENT. 


FOUND *****, STATEMENT 
DISCARDED. 

SYNTAX REQUIRES ‘COBOL' OR ‘LINK- 
AGE* AFTER ENTER VERB. OMIS- 


SION DOES NOT AFFECT 
PROCESSING. 


COMPILER ERROR. PHASE 4 TRYING 


TO GET DATA ATTRIBUTES FOR 
+R RACK, 


ITEQ4069I- 


IEQ4070I- 


ITEQ4071I- 
IEQ4072I- 


IEQ407,3I- 


TEQ4O74I- 


IEQ4075I- 


IEQ4076I- 


IEQ4O7T7I- 


IEQ4078I- 


IEQ4079I- 


IEQ4 080I- 


ITEQ4081I- 


ITEQ4 08 2I- 


TEQ4083I- 
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SYNTAX REQUIRES DEVICE-NAME. 
FOUND ***** IN **#*** STATEMENT. 
SYSTEM UNIT ASSUMED. 


AT-END CLAUSE MISSING. 
NEXT-VERB ASSUMED. 


AT-END- 


*#*##4* EXCEEDS LEGAL LENGTH. 
DISCARDED. 


EXIT FROM ***** PROCEDURE ASSUMED 
| BEFORE *****, 


***** SHOULD NOT APPEAR IN 
DECLARATIVE SECTION. STATEMENT 
ACCEPTED AS WRITTEN. 


Ex The statement will 
be compiled, but its use is 
illegal under standard COBOL 
rules and is not recommended. 


CONDITION-NAME INAPPROPRIATELY 
USED. SUBSTITUTING *****, 


‘NEXT SENTENCE! ILLEGAL AND DIS- 
CARDED. BOTH ***** AND NOT 
*#*4%% WILL CAUSE EXECUTION OF 
NEXT VERB. 


***#* REQUIRES *###** SUB- 
SCRIPT(S). SUBSTITUTING FIRST 
OCCURRENCE OF *****, 


*#**** MAY NOT BE USED AS A SUB- 
SCRIPT SINCE IT REQUIRES SUB- 
SCRIPTING ITSELF. SUBSTITUTING 
FIRST OCCURRENCE OF *****, 


SUBSCRIPT MUST BE INTEGRAL DATA- 
NAME OR LITERAL. FOUND NON- 
INTEGER *****, SUBSTITUTING 
FIRST OCCURRENCE OF *¥****, 


***#** FOUND AMONG SUBSCRIPTS. 


SUBSTITUTING FIRST OCCURRENCE 
OF *#*+#*, 


*DEBUG CARD MAY NOT REFER TO A 
PROCEDURE NAME WHICH ITSELF IS 
IN A DEBUG PACKET. CARD 
DELETED AND FOLLOWING STATE- 
MENTS ATTACHED TO IMMEDIATELY 
PRECEDING PACKET. 


**%*4* EXCEEDS **#*** CHARACTERS. 
UP TO 255 ACCEPTED. 


**#4%* TS NOT DEFINED AS SUB- 
SCRIPTED. SUBSCRIPTS 
DISCARDED. 


OCCURS-DEPENDING-ON VARIABLE MUST 
BE INTEGRAL NON-SUBSCRIPTED 
DATA-NAME. FOUND *****, ARBI- 
TRARILY SUBSTITUTING *****, 
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LTEQUO84I- 


IEQ4O085I- 


ITEQ4086I- 


IEQ4O87I- 


IEQUO88I- 


IEQU089I- 


IEQ4090I- 


ITEQ4U0911- 


IEQ4092I- 


IEQ4U093I- 


TEQ4O9UT- 


ITEQ4095I- 


TEQ4096I- 


IEQ4097I- 


IEQ4098I- 
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ILLOGICAL USE OF PARENTHESES 
ACCEPTED WITH DOUBTS AS TO 
MEANING. 


RECORD DESCRIPTION FOR FILE ***** 
MISSING OR ILLEGAL. STATEMENT 
DISCARDED. 


**%**e CONDITION USED WHERE ONLY 
IMPERATIVE STATEMENTS ARE LEGAL 
MAY CAUSE ERRORS IN PROCESSING. 


‘END DECLARATIVES!' MISSING OR 
MISPLACED. PROGRAM CANNOT BE 
EXECUTED. 


COMPILER ERROR. I-C TEXT COUNT 
FIELD 0. SKIPPING TO PHASE 5. 


*e*kKE/*EKEE SHOULD NOT BE TARGET 
FIELD FOR *###*/#*4##* JN *#44% 
STATEMENT. STATEMENT ACCEPTED 
AS WRITTEN. 


SORT-KEY MUST BE IN FIXED POSI- 
TION NOT MORE THAN 4092 BYTES 


FROM START OF RECORD. ***** 
DISCARDED. 
SYNTAX REQUIRES OPERAND. FOUND 


**4*4%*, TEST DISCARDED. 

EXTERNAL DECIMAL NAME USED IN 
TRANSFORM STATEMENT. STATEMENT 
ACCEPTED AS WRITTEN. 


ALL WRITE STATEMENTS FOR ****# 
SHOULD USE ‘AFTER ADVANCING! 
OPTION. STATEMENT ACCEPTED AS 
WRITTEN. 


***** TS IN A RECORD OF AN APPLY- 
WRITE-ONLY FILE, AND REFERRING 
TO IT MAY CAUSE ERRORS IF FILE 
IS OPENED AS OUTPUT WHEN ***** 
STATEMENT IS EXECUTED. 


WRITE FROM DATA-NAME REQUIRED FOR 
*e4%4%, TO WHICH WRITE-ONLY IS 
APPLIED. STATEMENT DISCARDED. 


*4#%4% STATEMENT WILL NEVER BE 
EXECUTED. 


Explanation: The logic of the 
COBOL source program prevents the 
computer from executing the 
statement noted. The compiler, 
however, accepts the statement as 
written. 


OPTION ILLEGAL FOR 
DISCARDED. 


UNIT (REEL) 
eK 


LABEL DECLARATIVE ILLEGAL FOR 
*44%*#, NON-QSAM FILE. 


IEQ4099I- 


IEQ5001I- 


IEQ5002I- 


IEQ5003I- 


TEQ5004I- 


IEQ5005I- 


IEQ5006I- 


IEQ5007I- 


IEQ5008I- 


IEQ5009I- 


NO EXIT SPECIFIED BEFORE END OF 
THIS DECLARATIVE SECTION. CON- 
TROL WILL FALL THROUGH TO NEXT 
SECTION. 


Explanation: Falling through 
will occur only under a specific 
set of circumstances. At other 
times the proper exit from the 
declarative procedure will be 
assumed. Check the generated 
code to determine action for 
execution. 


COMPILER LOGIC ERROR OR MACHINE 
ERROR. AN UNRECOVERABLE ERROR 
OCCURRED WHILE TRYING TO ASSIGN 
A DOUBLE REGISTER. COMPILATION 
ABANDONED. 


COMPILER LOGIC ERROR OR MACHINE 
ERROR. AN UNRECOVERABLE ERROR 
OCCURRED WHILE PROCESSING A 
SUBSCRIPTED DATA-NAME. COMPI- 
LATION ABANDONED. 


A DIVISOR IS A ZERO CONSTANT. 
RESULT OF DIVIDE WILL BE SET TO 
ALL 9'S. 


MORE THAN 255 SUBSCRIPT ADDRESS 
CELLS USED. PROGRAM CANNOT 
EXECUTE CORRECTLY. 


er Response From the map, 
determine the point at which the 
subscript address cell number 
(SBS) exceeded 255. Insert a 
dummy paragraph-name before the 
offending statement in the source 
program and recompile. 


COMPILER LOGIC ERROR OR MACHINE 
ERROR. AN UNRECOVERABLE ERROR 
OCCURRED WHILE PROCESSING A 
MOVE. COMPILATION ABANDONED. 


COMPILER LOGIC ERROR OR MACHINE 
ERROR. UNEXPECTED INPUT TO THE 
MOVE OR STORE PROCESSOR. COM- 
PILATION ABANDONED. 


COMPILER LOGIC ERROR OR MACHINE 
ERROR. UNEXPECTED INPUT TO THE 
ARITHMETIC CODE GENERATOR. 
COMPILATION ABANDONED. 


COMPILER LOGIC ERROR OR MACHINE 
ERROR. UNEXPECTED INPUT TO THE 
FLOATING-POINT ARITHMETIC ROU- 
TINE *FPCVBH'. COMPILATION 
ABANDONED. 


COMPILER LOGIC ERROR OR MACHINE 


ERROR. LOST SUBSCRIPT-ID IN 
TABLE 'XSSNT'. COMPILATION 
ABANDONED. 


IEQ5010I- A CONSTANT INTERMEDIATE RESULT 
HAD TO HAVE ITS HIGH ORDER 
DIGIT POSITION TRUNCATED. 


IEQ5011I- AN INTERMEDIATE RESULT OR A SEND- 
ING FIELD MIGHT HAVE ITS HIGH 
ORDER DIGIT POSITION TRUNCATED. 


IEQ5012I- COMPILER LOGIC ERROR OR MACHINE 
ERROR. LOST INTERMEDIATE 
RESULT ATTRIBUTES IN ‘XINTR‘ 
TABLE. COMPILATION ABANDONED. 


IEQ5013I- ILLEGAL COMPARISON OF TWO NUMERIC 
LITERALS. STATEMENT DISCARDED. 


OBJECT TIME MESSAGES 


IEQOOOA- XXX 


Explanation: This message is 
issued by an object program 
that was originally written 
in COBOL F language. The 
message text is supplied by 
the object program and may 
indicate alternative action 
to be taken. 


System Action: The object 
program enters wait state. 


Qperator Response: Follow 
the instructions given by the 


xx IEQ990D 


IEQ999I- 


programmer when he submitted 
the program for execution. 
If the job step is to be 
resumed, enter REPLY xx, 
where y is any single 
character. 


ays 


‘AWAITING REPLY‘ 


Explanation This message is 
issued by the object program 
when operator intervention is 
required. 


erator Res Issue a 
REPLY command. (The contents 
of the text field should be 
supplied by the programmer on 
the job request form.) 


NO DD CARD FOR DDNAME. 


Explanation: The operating 
system could not find a 


corresponding ddname on a DD 
statement for a file assigned 
in a SELECT clause. 


Qperator Response: User 
should have indicated either 
to continue processing or to 
cancel the job. Note that if 
the user elects to continue 
processing, any READ or WRITE 
encountered for the file will 
result in an ABEND. 
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*, in job control language 28,30,74,75 
restrictions with UNIT parameter 32 
/* Statement 13,40 
under MFT and MVT 84 


A, as a device class 13,17,39 
ABDUMP (see dump) 
abnormal termination 106,110,157,158 


incomplete 117 

requesting a dump 48 

size errors causing 193 
abnormal termination dump 

definition 110 

example of 114-117 

using 112 
ABSTR 33 

in QISAM 61 
ACCEPT 

Statement 80 

relationship to SYSIN DD 
Statement 48 

subroutine 177 
ACCESS clause 49,50 

in file processing techniques 
Accounting information 

in EXEC Statement ‘18 

in JOB Statement 16 
ACCT parameter 19,27 
ACTUAL KEY clause 

in BDAM 59 

in BSAM 54,57 

causing errors 112 

in file processing techniques 183 
address constant table 193 
AFF parameter 28,31 
Allocation messages 

compiler 97 


182-187 


99,103-105 


sample 172 
ALX 33 
argument list 147 
arguments 


compared to parameters 146 
arithmetic subroutines 177,179 
assembler language 145-149 

sample 168-171 

using EXEC Statement 21 
ASSIGN TO clause 

in BDAM 59 

in BSAM 57 

in QSAM 52 

in Sort Feature 131 

relationship to DD Statement 
ATTACH macro instruction 191 
automatic call library 46,138,139 


48,155 


B, aS a device class 13,39 
base and displacement 100 
BASIS option in job control language 
BASIS Statement 20,78,139-42 
in a debug packet 110 
error messages involving 199 


22,27 


BCD 159 
BDAM 
data control block 187 
DD Statement parameters 58,59 
defining a data set in 50 
definition of 9 
error processing for 156-158,196 
permissible COBOL Clauses 59 
restrictions with job control 
language 58 
beginning address of word 34 
BFALN 182,184,185 
BFTEK 182,185 
binary (see also COMPUTATIONAL) 
data items 122 
intermediate results 127 
subroutines 178,179 
BISAM (see also QISAM) 58-67 
considerations when using 
data control block 186 
defining a data set in 50 
definition of 9 
error conditions 
error processing for 
processing with 66,67 
BLKSIZE 41,47,53,189 
for file processing techniques 
in QISAM 62 
in Sort feature 132,133 
BLOCK CONTAINS clause 32 
in file processing 
techniques 182,184,185 
in QSAM 52 
block length (see BLKSIZE) 
block size 
causing errors 112 
for utility data sets 
blocking words 47,50 
BSAM 53-57 
data control block 183 
DD Statement parameters 57 
defining a data set in 50 
definition of 9 
error processing for 156-158,195 
permissible COBOL clauses 57 
uses of DUMMY parameter 30 
WRITE and CLOSE subroutine 179 
BUF option 21,27,190 
BUFCB subparameter 182,184,185 
buffers (see also BUFCB, BUFNO) 
allocating space to 189,190 
determining number of 61 
specifying number of 53 
BUFNO subparameter 53,61,182-185 


66,67 


197,198 
156-158 


182-185 


189,190 


182-185 


CALL Statement 145 

catalog, system 9 

cataloged data sets 
creating 71 
retrieving 73,74 


63,75 
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Cataloged procedures 
bypassing steps within 19 
calling 31,81,82 
COBFC 84,85 
COBFCLG 84,85 
COBFLG 84,85 
data sets produced by 
definition of 13 
limiting execution time of 23 
modifying 86-89 
-programmer-written 83 

restrictions 83 
relationship to SYS1.PROCLIB 81 
required device class names for 32 
restarting programs within 20 
system 82,83 
using the DD Statement 
using the EXEC Statement 

CATLG subparameter 39,75 

character delimiters 
as text 15 
in job control language 15 

checkid 17,93 

checkpoint data set 16 

Checkpoint/Restart 91-95 
methods 91 
parameters in JOB Statement 16 
parameters in EXEC Statement 20 
RD parameter 16,20, 93 
RESTART parameter 17,94 
subroutine 180 
SYSCHK DD Statement 94 

Checkpoints 
considerations 93 
how taken 16 

CHKPT macro instruction 95 

CLASS parameter 17,26 

Class Test subroutine 180 

classname, as a SYSOUT subparameter 39 

CLIST option 21, 27,101,189 

CLOSE Statement 128 
under MFT and MVT 162 

CLOSE REEL Statement 54 


81, 82 


87-89 
86,87 


COBFC 81, 83-85 
COBFCLG 83-85 
COBFLG 83-85 
COBOL 


sample program 165-175 
COBOL Subroutine library 138 
Comments field in job control language 15 
Compare subroutine 179 
compilation 
data sets for 42 
example of job control statements 
job step 10 


77,78 


sample 165-171 
using the REGION parameter 161 
Compiler 


calling 191,192 

capacity 193,194 

data sets 41,42 

definition of 10 

diagnostic messages 
summary of 199-213 

internal name 99 

machine requirements. 161 

optimization 189,190 

options 27 
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output 97-102 
specifying in EXEC Statement 18 
Compiler options 
in EXEC statement 18, 21,22 
completion code 117 
in Sort programs 136 
COMPUTATIONAL 
conversions involving 123-125 
efficient use of 119 
COMPUTATIONAL-1 data items 
COMPUTATIONAL-2 data items 
COMPUTATIONAL- 3 
conversions involving 123 
COND parameter 26,27,102 
in cataloged procedures 86 
in EXEC Statement 19 
in JOB Statement 16 
testing return codes 199 
conditional, as a severity level 
(Cc) 101,199 
Conditions terminating execution 
in JOB Statement 16 
CONTIG subparameter 33 
in BSAM 55 
in QISAM 61 
Continuation of Job Control Statements, 
rules 15,16 
control section 
length 104 
relative location 104 
conversion subroutines 177 
copy library (see also source program 
library) 139 
COBOL sequence numbers 141 
entering source statements 139 
IEBUPDTE sequence numbers 141 
retrieving source statements 140 
updating source statements 139,140 
COPY option in job control language 22,27 
used in cataloged procedures, 
example 88 
COPY Statement 20, 22,78, 139-140 
error messages 199,201 
cross reference list 103,104 
used in dumps 113-117 
cross reference table 172 
CYL 33,34, 61 
CYLOFL 184 


124-126 
124-126 


104,172 


data alignment 123-126 
use of PICTURE 122,127 
data control block (see also DCB parameter) 
fields 181-187 
data conversion 123-125 
Data Division 
programming techniques 119-126 
used in Report Writer 129 
data formats 123-126 
DATA parameter 
in DD Statement 28,30 
restrictions with UNIT parameter 32 
specifying input with 74 
data set 
adding records to (also see MOD 
subparameter) 38 
blocked 47,48,189 


cataloged 39,63,75 
cataloged procedures producing 81,82 
checkpoint 16 
COBOL clauses used to specify 48 
compiler 41,42 
concatenated 90 
definition of 9 
deletion of 38 
disposition of 38,39 
after abnormal termination 117 
errors 111 
generation 75,76 
header label group 159 
labels 158-160 
linkage editor 45,46 
names 31 
restrictions 76 
organization of 9,10, 58-67 
(see also the individual access 
methods) 
partitioned 10 
retaining 38 
retrieving 73,74 
scratching 118 
under MFT and MVT 118 
sharing 38 
for Sort programs 132-134 
specifying space for 33-35 
temporary 31,35,71 
data set control block 160 
data set label 
relationship to DD Statement 156 
data set member 10 
DATE-COMPILED clause 99 
DCB macro instruction 181 
DCB parameter (see also data control 
block) 155,28,49,189 
BISAM, used in 64 
BSAM, used in 56 
description of 31 
checkpoint/restart uses of 92 
creating data sets with 69,70 
error processing with 156,196,198 
identifying information in 155 
QISAM, used in 61,62, 64 
QSAM, used in 51-53 
retrieving data sets with 73,74 
Sort feature uses of 133 
DD Statement 9, 24-40, 69-76 
access methods using 


BDAM 59 
BSAM 57 
QISAM 60-63 
QSAM 52 


checkpoint/restart uses of 91,92 
changing libraries with 143 
creating libraries with 137 
error recovery option 156,157 
format of 28,29 
relationship to SELECT Statement 156 
Sort feature, used in 131-135 
ddname 
in a cataloged procedure 30 
used to allocate space 34 
DDNAME parameter 28,182-187 
cataloged procedures, used in 89,90 
description of 30 
error message 213 


debug packet 109 
debugging language 107-110 
(see also TRACE Statement and EXHIBIT 
Statement) 
DECB 
error conditions 196,197 
error processing with 156 
linking with 145 
Decimal-point alignment 122 
DECK option 22,27,77,102 
in cataloged procedures, example 86 
Declaratives 
USE AFTER STANDARD ERROR 156-158 
DEFER parameter 32 
DELETE Statement 72,141,142 
DELETE subparameter 38 
used for cataloged data sets 75 
Delimiter job control statement 13,40 
DEN subparameter 51 
DEVD 182,183 
device allocation 99 
device class 9 
blocking restrictions 32 
names 32 
diagnostic messages 97,99,101 
with ON Statement 107 
summary Of 199-213 
direct-access 
data set 
beginning address 34 
specifying directory for 34 
specifying space for 33-35 
device 
for compiler 161 
labels 158-160 
Sort feature programs 131,163 
storage capacity 55 
track capacity 56 
volume 
characteristics of 35,36 
disaster, aS a severity level (D) 102,199 
DISP parameter 29 
data set uses 
cataloging 75 
creating 69,70 
retrieving 73,74 
default values of 39 
description of 38 
in JOBLIB DD Statement 40 
in Sort feature 133 
DISPLAY Statement 80,106 
conversions involving 123-125 
relationship to DD Statement 47 
DISPLAY subroutine 177 
disposition messages 102-105 
DMAP option 21,27,99 
DSCB (see data set control block) 
DSNAME parameter 28 
in creating data sets 69,70 
description of 30 
in QISAM 60,61 
in retrieving data sets 69,70 
in Sort feature 133 
DSORG 182-187 
values of 
DA 56 
IS 61 
DUMMY parameter 28,30 
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dummy records 54 
in QISAM 64 

dumps 
determining location of error 112 
errors causing 110-112 


requesting 48,106 
using SYSABEND DD Statement 110 
types of 


abnormal termination 110 
indicative 110 


EBCDIC 51,159,160 
ENTER Statement 145 
entry name 104 
ENTRY Statement 145 


EODAD 182,183,185 
EROPT subparameter 52,53,110,182,195 
error 
as a severity level (E) 102,199 
conditions 


for BDAM 196 

for BISAM/QISAM 196-198 

for BSAM/QSAM 195 

input/output 195-198 
messages 

return codes 20 

severity codes 20 


options 182-185 
processing 156-158 
recovery 


DD Statement option 
system 156 
table 193 
ESD (see external symbol dictionary (ESD) ) 
ESETL macro instruction 65 
EXEC Statement 9,18-24 
to call cataloged procedures 81 
in checkpoint/restart 93 
for compiler optimization 189 
format of 27 


156,157 


Execution 
definition of 10 
job step 
example of job control 
language 79,80 
output 105,106 
sample 175 


storage allocation 162 
with the REGION parameter 
EXHIBIT Statement 80,107-110 
relationship to SYSOUT DD Statement 48 
EXHIBIT subroutine 177 
EXPDT subparameter 38 
external decimal subroutines 178 
external floating point subroutines 178 
external name 
defined 148 
external reference 
defined 148 
external symbol dictionary (ESD) 102 


161,162 


FB 
for device types 189 
in Sort feature 132 
FD 49,100 
relationship to DCB 155 
with WRITE AFTER ADVANCING 50 


218 


file 
distinction with data set 48 
file-name 48,49 
File processing techniques 49-67 
(see also BISAM, BDAM, BSAM, QSAM, 
QISAM) 
FILE-LIMIT Clause 53 
in BDAM 58 
FLAGE option 
FLAGW option 
floating point 
error messages 202 
floating-point data items (see also 
COMPUTATIONAL-1 and COMPUTATIONAL-2) 
intermediate results 127 


22,27 
22,27 


generation data set 75,76 
GIVING option 131 
global table 100 
MAP option 21 
glossary 98,99,101 
requesting through EXEC Statement 21 
GO TO Statement 
causing errors 111 
used in a debug packet 110 


IEBUPDTE 82, 83,139-142 
IEHLIST 118 
IEHMOVE 137 
IEHPROGM 118 
IEQ 101,199 
IEQCBLOO 18 
IEWL 18 
IHDFACPT 177 
IHDFDISP 177 
IHDFSORT 136 
INCLUDE linkage editor 
statement 142,150,151 
INCLUDE Statement 22,78,139,140 
error messages 199 
index 
in QISAM 58 
master 64 
INDEX 
in QISAM 61,63 
indexed sequential access methods (see 
QISAM) 
indicative dump 110 
restriction for MVT 112 
information messages 103,104 
input/output subroutines 177 
input stream 
specifying control statements for 30 
reading more than one 11 
INSERT Statement 141,142 
instruction address 
causing interrupt 116,117 
intermediate results 126-128 
internal decimal subroutines 
internal floating point 
subroutines 178,179 
interrupt address, example 116 
invalid data 
causing abnormal termination 111 
INVALID KEY clause 156-158 
in file processing techniques 184 
invalid key error conditions 196-198 


178,179 


job, definition 9 
job control language 
character delimiters 15 
coding 14 
examples of 
compilation 97 
linkage editing 103 
fields of 
comments field 15 
name field 14 
operation field 15 
operand field 15 
notation used in 26 
statement continuation rules 15 
types of 
DD statement 24-40 
Delimiter Statement 40 
EXEC Statement 18-24 
JOB Statement 16-18 
job control procedure 13,14 
job Control Statements 
format of 14-40 
listing of 14 
job library 142 
job management 14 
job scheduler 14 


JOB Statement 9,16-18 
format of 26 

job step 
bypassing 


using JOB Statement 16 
using EXEC Statement 19 
definition of 9 
deferring 17 
JOBLIB CD Statement 40,79, 80,142,153 
restriction with cataloged procedure 82 
restriction with DDNAME parameter 89 
jobname 16 


KEEP subparameter 38 

used with checkpoint/restart 92 
KEY clauses 54 

(see also SYMBOLIC KEY, ACTUAL KEY) 
key length 184,187 
KEYLEN 184,187 
keyword parameters 15 


label 
nonstandard 159 
volume 158-160 


LABEL parameter 29,37,159 


in creating data sets 70,71 


in retrieving data sets 73,74 
in Sort feature 133 
library 10,137-143 
changing 143 
compilation, use of 42,43 


concatenating 40,142 
creating 72 
directory 137 
kinds of 
automatic call 
copy 139 
job 142 
link 137 
private 40 
procedure 138 
source program 139 


46,138,139 


system-provided 78,79,137,138 
sort 138 
user-defined 79,139 
linkage editing, use of 46 
members of 
adding 72 
replacing 72 
retrieving 74 
relationship to JOBLIB DD 
Statement 40,46 
relationship to SYSLIB DD 
Statement 42,43 
subroutines 46,177-180 
arithmetic 177 
COBOL 138 
conversion 177-179 
input/output 177 
intermediate results 127 
LIBRARY linkage editor 
Statement 139,142,151 
LIMCT 187 
LINE-COUNTER 130 
LINECNT option 22,27,97 
LINK macro instruction 
linkage 
for error processing handling 156,157 
linkage conventions 145,147 
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